Re: [Netconf] a joint discussion on dynamic subscription

"Eric Voit (evoit)" <evoit@cisco.com> Thu, 14 June 2018 15:04 UTC

Return-Path: <evoit@cisco.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F37A130E62 for <netconf@ietfa.amsl.com>; Thu, 14 Jun 2018 08:04:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uxAqOyC7OL5M for <netconf@ietfa.amsl.com>; Thu, 14 Jun 2018 08:04:04 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BEE2130E29 for <netconf@ietf.org>; Thu, 14 Jun 2018 08:04:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15852; q=dns/txt; s=iport; t=1528988644; x=1530198244; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Wz4/IHoA2ZafQEgl1HIDOOqr7CYq1130xqGZCs71DZI=; b=kK2htUlpeA3uNNeBtAqvvaXKF7NBxywTdZNcsb2ZFyv6cUxljgQKJgn7 Keybq65Bcv699tIpAfz3qoIbEPK+iB0x8ZiXsCQfHqL+tNfIfE2eHmoGE 9NW11WqPswb9Lb0FMQXbYMxdVoennk1Rluq9/nLI/L/nbk8vS74VZ/9kr E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DoAQB0giJb/4wNJK1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYJTdWJ/KAqYRIF/j26Ef4F4C4FWgxYCgkUhNRcBAgEBAQE?= =?us-ascii?q?BAQJtKIUoAQEBAwEMGwZMBQsCAQgOAgIDEBoHMhQDDgIEAQ0FCIMcgRtcCKw?= =?us-ascii?q?uM4hGgWiITIFUP4EPgl4uhF+FbAKHUJE+CQKOd41AkRoCERMBgSQeATaBUnA?= =?us-ascii?q?Vgn6CIReOF2+PH4EaAQE?=
X-IronPort-AV: E=Sophos;i="5.51,222,1526342400"; d="scan'208,217";a="129036821"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jun 2018 15:04:02 +0000
Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id w5EF42W1009289 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Jun 2018 15:04:02 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 14 Jun 2018 11:04:02 -0400
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Thu, 14 Jun 2018 11:04:01 -0400
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Martin Bjorklund <mbj@tail-f.com>, "j.schoenwaelder@jacobs-university.de" <j.schoenwaelder@jacobs-university.de>, Tianran Zhou <zhoutianran@huawei.com>, "Zhengguangying (Walker) (zhengguangying@huawei.com)" <zhengguangying@huawei.com>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [Netconf] a joint discussion on dynamic subscription
Thread-Index: AdQCx01ede4gaRHPTgG2WyMdkd0r2gARka+AADD1vgAAAsT/AAACxI2AAAe7UgAABvBhUA==
Date: Thu, 14 Jun 2018 15:04:01 +0000
Message-ID: <7d8930974acf4fd28b7e60a24c5d2196@XCH-RTP-013.cisco.com>
References: <20180614.091828.21142123428745204.mbj@tail-f.com> <20180614.103746.8291316293283106.mbj@tail-f.com> <20180614095701.74rqetmhark3tzpd@anna.jacobs.jacobs-university.de> <20180614.153824.1029993696264171685.mbj@tail-f.com>
In-Reply-To: <20180614.153824.1029993696264171685.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.228]
Content-Type: multipart/alternative; boundary="_000_7d8930974acf4fd28b7e60a24c5d2196XCHRTP013ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/bKBTW95cMwPJaFUrxUPVPTLiuqw>
Subject: Re: [Netconf] a joint discussion on dynamic subscription
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Jun 2018 15:04:12 -0000

> From: Martin Bjorklund, June 14, 2018 9:38 AM

>

> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de<mailto:j.schoenwaelder@jacobs-university.de>> wrote:

> > On Thu, Jun 14, 2018 at 10:37:46AM +0200, Martin Bjorklund wrote:

> > >

> > > Also, I think it would be useful to draw a picture that demonstrates

> > > the roles:

> > >

> > >       subscriber/client    receiver

> > >           |                   ^

> > >           | (1)               | (3)

> > >           |                   |

> > >           |                   |

> > >           v        (2)        |

> > >         server  ----------> publisher

> > >

> > > (1) is creation of the subscriptionE; dynamic or configured

> > > (2) is implementation specific

> > > (3) is the delivery of notifications / event records

> > >

> > > NOTE: the subscriber and receiver MAY be the same entity

> > > NOTE: for some transports, if (1) is dynamic, (3) is sent over the

> > >       same session as (1)

> > > NOTE: for some transports, the sevrer and publisher are the same

> > > entity

> >

> > So why do we need the distinct role of a publisher?



I would argue that the server and publisher are the same (see below for why).  If this is true perhaps we could define the term "distributed publisher" which matches to the term "Subscribed Domain" in draft-ietf-netconf-udp-pub-channel.  A distributed publisher would be a type of publisher, inheriting all requirements for that device from subscribed-notifications.



If this is acceptable, then (2) is an implementation detail which can be hidden.  This addresses Juergen's comment that having (2) inserts error conditions which might need to be understood by the outside world.   My mental model for udp on mult-linecard  (when building on the terminology of subscribed-notifications) would be something like:



       subscriber        receiver

           |             ^     ^

           | (1)         | (3) |

            |             |     |

        .---V-------------|-----|-------.

       | .------.  .-------. .-------. |

       | |master|  | agent | | agent | |

        | '------'  '-------' '-------' |

       |    distributed  publisher     |

        '-------------------------------'



Note that this is very close to figure 1 of the UDP draft.  The difference is that it gets rid of the 's' in Agents and Receivers.  And turns subscribed domain into a single publisher.  This allows the hiding of error states between master and agent.



Note that this is different than the distribution of terms within draft-zhou-netconf-multi-stream-originators.  And some work would be needed there to merge the terminology.



> > > If we can agree on an architectural picture like this, the different

> > > transport docs can refer to this architecture and be defined related

> > > to it.   For example, the netconf transport doc can state that the

> > > publisher is always the same entity etc.

> >

> > So we introduce the role of a publisher because of some transports

> > that do have a server?

>

> I assume you mean "do not".  Yes, that's my understanding.  But I might be

> wrong.  Eric and Alex?



The term "server" is only used once in draft-ietf-netconf-udp-pub-channel.   And then it refers to "push server".  I am assuming the "push server" is a publisher.  Based on this, I do believe we can get away from using the term "server".

Eric



> > If the publisher is truely distinct entity from the server (and the

> > state it has), we may get interesting security considerations to

> > write.

>

> Isn't this what the UDP transport does?  It uses a NETCONF/RESTCONF server

> to set up the subscription, then UDP to send the notifications.

>

>

> /martin