Re: [netconf] configuring multi-channels

Tianran Zhou <> Wed, 18 September 2019 01:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CC74D120131 for <>; Tue, 17 Sep 2019 18:47:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.801
X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kbcb6jTwi9wV for <>; Tue, 17 Sep 2019 18:47:57 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8900012011E for <>; Tue, 17 Sep 2019 18:47:57 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id 979673534C4BFB4EF309 for <>; Wed, 18 Sep 2019 02:47:55 +0100 (IST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 18 Sep 2019 02:47:54 +0100
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Wed, 18 Sep 2019 02:47:54 +0100
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Wed, 18 Sep 2019 02:47:54 +0100
Received: from ([fe80::a54a:89d2:c471:ff]) by ([]) with mapi id 14.03.0439.000; Wed, 18 Sep 2019 09:47:47 +0800
From: Tianran Zhou <>
To: Andy Bierman <>, Martin Bjorklund <>
CC: Netconf <>
Thread-Topic: [netconf] configuring multi-channels
Thread-Index: AdVs9BeNNLIBQRFAQtOat+1DuA9kN///1euA//92JkCAAJSVAP//crMggACh+gD//3goMAASRjAA//94jtD//2m1AP/+TBRw//0bfwD/+euegP/z1ZuA/+eiQQD/zhQBEA==
Date: Wed, 18 Sep 2019 01:47:46 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_BBA82579FD347748BEADC4C445EA0F21BEFB8820NKGEML515MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [netconf] configuring multi-channels
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 18 Sep 2019 01:48:00 -0000

Hi Andy and Martin,

The proposal in draft-zhou-netconf-multi-stream-originators is to add the read only message-generator-id.
So that the receiver can verify the full set of YANG objects promised are being provided across the sum of stream originators.

   module: ietf-multiple-stream-originators
     augment /sn:subscriptions/sn:subscription:
       +--ro message-generator-id*   string
     augment /sn:subscription-started:
       +--ro message-generator-id*   string
     augment /sn:subscription-modified:
       +--ro message-generator-id*   string
     augment /sn:establish-subscription/sn:output:
       +--ro message-generator-id*   string
     augment /sn:modify-subscription/sn:output:
       +--ro message-generator-id*   string

So we are not going to configure a channel-id or message-generator-id.

I am just thinking how to configure the transport when there are multi originators. If draft-zhou-netconf-multi-stream-originators need to provide some guidelines or it’s deferred to the transport documents like https-notif.


From: netconf [] On Behalf Of Andy Bierman
Sent: Tuesday, September 17, 2019 11:20 PM
To: Martin Bjorklund <>
Cc: Netconf <>
Subject: Re: [netconf] configuring multi-channels


On Tue, Sep 17, 2019 at 7:48 AM Martin Bjorklund <<>> wrote:
Kent Watsen <<>> wrote:
> Martin,
> As for why there is a need to configure anything on a per-channel
> basis, here are some possible reasons:
>   - different TCP-level parameters (source IP, possibly a VRF)

Perhaps.  But setting this per linecard would require the client to know
all the line cards and which IP each line card can use.

>   - different TLS-level parameters (TA cert, client cert)

Do you see a use for this?

>   - different HTTP-level parameters (basic auth)

Do you see a use for this?

> Does any of this matter?  Is the only issue if the receiver can know
> which line card sent the message?  Or is it needed to enable the
> networking connection to be established, which can somehow be
> different amongst the line cards?
> If we purposely shun variations, then the need to configure anything
> per-channel goes away, which would make things much easier all around.
> But then we'd have to ask, what remains in the
> multi-stream-originators draft?

I don't know, but if we can solve the problem w/o an additional
specification, that seems like a good thing!

+1 to all of Martin's concerns.

The notification already has a subscription-id, maybe a message-generator-id.
Is the proposal to add an arbitrary channel-id to the notification header?

It seems simpler and possibly useful to the client to retrieve the read-only message-generator-id
that is being used for connection (from this new module).
This should not be configurable by the client and a new arbitrary number should not be invented for it.



netconf mailing list<>