Re: [Netconf] IETF 101 SN Question 1: Proper designation of receiver

"Eric Voit (evoit)" <evoit@cisco.com> Tue, 26 June 2018 19:30 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 1DA2F13113D for <netconf@ietfa.amsl.com>; Tue, 26 Jun 2018 12:30:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 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_MED=-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 Wkcw0iLsns7G for <netconf@ietfa.amsl.com>; Tue, 26 Jun 2018 12:30:42 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82B4B131134 for <netconf@ietf.org>; Tue, 26 Jun 2018 12:30:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11429; q=dns/txt; s=iport; t=1530041442; x=1531251042; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ZKLqLXQwZLPvwcc8XP16riNIR7gcst3HQ9xElDQjoAI=; b=eIHMvrK7cW+bzBLGirWgnThwDEIxp51YqciWCYiO9pBqGRHhI+i8nS2v 3WG0o5DdD20QF4WQhWQNa7S6Rq3TU8flaVZjoqH9Q0oJzf6Kq/rjK0Yel f+HDet/2VVWoHaBW+3ow60EuJFHH0bBg1CmQ9vKhRA8l9SQq55/gzNLMd k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DsBAAKkzJb/4sNJK1SChkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGDKgEBAQEcBWJ/KAqaP5UVgXoLhGwCgxMhNRcBAgEBAQE?= =?us-ascii?q?BAQJtKIU2AQEBAwE6PwULAgEIDgcDDREQMiUCBA4FCBODC4F3CK9yiEqBHIh?= =?us-ascii?q?tgVY/gQ+DD4FBgw4VhWwCjEYBjGoJAo8KgUiGcYUZkUoCERMBgSQfATWBUnA?= =?us-ascii?q?VO4JpgiMXjhdvjmaBGgEB?=
X-IronPort-AV: E=Sophos;i="5.51,275,1526342400"; d="scan'208";a="135301540"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jun 2018 19:30:41 +0000
Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id w5QJUf3T019522 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Jun 2018 19:30:41 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 26 Jun 2018 15:30:40 -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; Tue, 26 Jun 2018 15:30:40 -0400
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Martin Bjorklund <mbj@tail-f.com>
CC: "kwatsen@juniper.net" <kwatsen@juniper.net>, "netconf@ietf.org" <netconf@ietf.org>, "Tim Jenkins (timjenki)" <timjenki@cisco.com>, "alex@clemm.org" <alex@clemm.org>
Thread-Topic: [Netconf] IETF 101 SN Question 1: Proper designation of receiver
Thread-Index: AQHT7qZjKKPiRp7oL0Gw54ItH09w2qQ1f5yAgABaRoCAAFIXAP//0cbAgCYz3oCAALf2gIALzo6AgACF3OCAAIGQgP//v4TQgAHRv4D//78WkABEsRYAAAapTSAAjo35gAAIQuKQABHb3oAACd63QAAMMw8AAAhG1QA=
Date: Tue, 26 Jun 2018 19:30:40 +0000
Message-ID: <01cdb70696e84d7387e1ef7c72d65fc7@XCH-RTP-013.cisco.com>
References: <c034b39204074d36abdc9f57a6d7537b@XCH-RTP-013.cisco.com> <20180626.101045.358495650140202205.mbj@tail-f.com> <58867a306a1b4c2db94d98726a8fb40e@XCH-RTP-013.cisco.com> <20180626.204240.1818961627525784145.mbj@tail-f.com>
In-Reply-To: <20180626.204240.1818961627525784145.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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/eonE_VScDN-NetwjiEGt7tm3aoo>
Subject: Re: [Netconf] IETF 101 SN Question 1: Proper designation of receiver
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: Tue, 26 Jun 2018 19:30:50 -0000

> From: Martin Bjorklund, June 26, 2018 2:43 PM
> 
> "Eric Voit (evoit)" <evoit@cisco.com> wrote:
> > > From: Martin Bjorklund, June 26, 2018 4:11 AM
> > >
> > > "Eric Voit (evoit)" <evoit@cisco.com> wrote:
> > > > > From: Kent Watsen, June 25, 2018 3:43 PM
> > > > >
> > > > > >> >> <kent-orig> Okay, glad to see that you embrace using
> > > > > >> >> ietf-netconf-server, rather than ietf-netconf-client.  And
> > > > > >> >> I'll grant you that it's infinitely more likely that the
> > > > > >> >> ietf-netconf-server module would be implemented (i.e., the
> > > > > >> >> top-level /ncs:netconf-server container exists), more so
> > > > > >> >> than the ietf-netconf-client module would be implemented.
> > > > > >> >> The WG created the top-level /ncc:netconf- client
> > > > > >> >> container more for the sake of symmetry than for having a
> > > > > >> >> use-case for when it would be implemented.  I think the
> > > > > >> >> question to ask is, is it
> > > > > >> possible that a device wants to use SN but doesn't
> > > > > >> *implement*
> > > > > >> ietf-netconf- server?
> > > > > >> >>
> > > > > >> >> <Eric> Yes, this will be possible.  Reasons would include:
> > > > > >> >> alternative
> > > > > >> transports
> > > > > >> >> (COMI, UDP), HTTP2 configured subscriptions (which might
> > > > > >> >> use
> > > > > >> >> ietf-restconf- server), or no need for a publisher to
> > > > > >> >> include the configured subscriptions feature.
> > > > > >> >>
> > > > > >> >> <Kent> I should've be more specific: is it possible that a
> > > > > >> >> device would use netconf-notif (where your leafref is
> > > > > >> >> defined) but not implement
> > > > > >> ietf-netconf-
> > > > > >> >> server?  Similarly, restconf-notif would presumably have a
> > > > > >> >> leafref to
> > > > > >> >> ietf-
> > > > > >> >> restconf-server, etc.
> > > > > >> >
> > > > > >> >Yes.  Cases would include:
> > > > > >> >(a) platform doesn't support configured subscriptions
> > > > > >> >(b) vendor has not yet implemented ietf-netconf-server, and
> > > > > >> >uses something
> > > > > >> else.
> > > > > >>
> > > > > >> (a) is this a valid case?  - I thought this conversion only
> > > > > >> regards configured subscriptions.  No leafref or equivalent
> > > > > >> would be needed to support a dynamic subscription.  Right?
> > > > > >
> > > > > > Correct.  But your question was "can you use netconf-notif
> > > > > > without a leafref
> > > > > to...".
> > > > > > Needing both drafts is absolutely the case for dynamic
> > > > > > subscription support, and ietf-netconf-server would not be needed
> here.
> > > > >
> > > > > I read the above a few times, but I'm having a hard time
> > > > > understanding it.  Can say it differently or provide an example?
> > > >
> > > > Dynamic subscriptions over NETCONF requires
> > > > draft-ietf-netconf-netconf-event-notifications.  With these
> > > > deployments, there there is no call home, there is no
> > > > configuration, and there need be no ietf-netconf-server.yang
> > > > leafref (or use of ietf-netconf-server.yang grouping).
> > > >
> > > > > >> (b) this seems like a possibility, but then I think this make
> > > > > >> the case for why a leafref to the global *conf servers
> > > > > >> definitions won't always
> > > > > work.
> > > > > >
> > > > > > Agree that nothing here will always work.  Deployments
> > > > > > commonly will have a heterogeneous mixture of model ecosystem
> models.
> > > > > >
> > > > > > This actually makes a *very* strong case for why the leafref
> > > > > > should be added as an augmentation from the *conf-server models.
> > > > > > That way leafref augmentations are explicitly tied to the
> > > > > > actual implementation of the
> > > > > model against which they refer.
> > > > >
> > > > > Not in the *conf-server models, the augments go into the
> > > > > *conf-notif models, I assume that is what you meant.
> > > >
> > > > My assertion is a good solution would be updating
> > > > ietf-netconf-server.yang per what is below.  Note that an answer
> > > > even further below regarding the sharing of a single NETCONF
> > > > session across multiple subscriptions and typical RFC6241 protocol
> > > > interactions is assumed.  But we could also insert your
> > > > ietf-netconf-server.yang grouping just as effectively where the leafref is
> seen.
> > > >
> > > > Anyway here are the following changes which would be made to
> > > > ietf-netconf-server.yang
> > > >
> > > >   import ietf-subscribed-notifications { prefix sn; }
> > > >   import ietf-netconf-subscribed-notifications { prefix nsn; }
> > > >
> > > >   feature subscription-support {
> > > >     description
> > > >         "The 'subscription-support' feature indicates that the NETCONF
> server
> > > >          supports configured subscriptions over call-home connections.";
> > > >        reference
> > > >         "RFC xxxx: Customized Subscriptions to a Publisher's Event Streams";
> > > >      }
> > > >
> > > >  augment "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver" {
> > > >    if-feature "subscription-support";
> > > >    when 'derived-from(../../../transport, "nsn:netconf")';
> > > >    description
> > > >       "This augmentation allows NETCONF specific parameters to be
> exposed
> > > >       for a receiver.";
> > > >     leaf netconf-endpoint {
> > > >       type leafref {
> > > >         path "/ncs:netconf-server/ncs:call-home/ncs:netconf-
> client/ncs:name";
> > > >       }
> > > >       description
> > > >         "Remote client which need to initiate the NETCONF transport if an
> > > >         existing NETCONF session from that client is not available.";
> > > >     }
> > > >   }
> > > >
> > > > With such a construct, it is impossible to add a leafref (or
> > > > grouping) within ietf-subscribed-notifications unless
> > > > ietf-netconf-server.yang exists.
> > > >
> > > > > >> This is why I
> > > > > >> was thinking before that your modules might themselves *use*
> > > > > >> the
> > > > > >> *conf- server-groupings (while pruning out unneeded parts,
> > > > > >> e.g., the "listen" subtree), so that it's independent of what
> > > > > >> the system has implemented at the global level.
> > > > > >
> > > > > > If you have 500 subscriptions, you then have to populate 500
> > > > > > identical
> > > > > groupings.
> > > > >
> > > > > No, you have one grouping, with 500
> > > > > /netconf-server/call-home/netconf-client
> > > > > instances.
> > > >
> > > > Yes.  But I don't know why someone would voluntarily do add 500
> > > > repeated elements to a configuration datastore.
> > > >
> > > > > >  And yes this is possible.  But it makes the part of me which
> > > > > > likes Normalized  data quite uncomfortable.
> > > > > >
> > > > > > But as I said before, it the WG wants such redundancy, fine.
> > > > > > Either choice need not impact decisions as part of LC.
> > > > >
> > > > > I don't believe that is a WG-preference thing, so much as an
> > > > > outcome of the current design, which is that each receiver for
> > > > > each subscription has its own state-machine and protocol
> > > > > messages.  There is no sharing; no two receives can use the same
> > > > > RFC 6241 NETCONF session, which effectively translates to each
> > > > > receiver having its own /netconf-server/call-home/netconf-client
> > > > > instance,
> > > > > right?
> > > >
> > > > This is incorrect.  Protocol and state-machine messages have been
> > > > decoupled from the transport session.
> > > >
> > > > I am not sure why you think that subscriptions are unable to use a
> > > > common NETCONF session?  Implementations of dynamic NETCONF
> > > > subscriptions have been doing this for years.  Subscription
> > > > multiplexing of configured and dynamic subscriptions over a common
> > > > transport is a pre-requisite for solution scalability.
> > >
> > > I don't think muliplexing of configured and dynamic subscriptions
> > > over a single session is possible.
> > >
> > > If this is the intention of the current design, the document needs
> > > to explain how this is supposed to be done.
> >
> > What is your concern?
> 
> Suppose a client connects to a server and starts a dynamic subscription.  Can
> this session somehow be used for a configured subscription?  I assume not.

Why not?

> > > Multiplexing multiple configured subscriptions over a single
> > > transport session could be possible, but the document doesn't mention
> this.
> > > Again, if this is the intention, it needs to be properly described
> > > in the document.
> >
> > What is missing?  The subscribed-notification draft section 2.5.1 and
> > Figure 9 describe how each receiver is pushed their own state
> > notifications.  (I.e., the state machine is per-receiver.  It is not
> > per-subscription, nor is it per-transport.)
> 
> If there are two different subscriptions configured, each has its own list of
> receivers.  Under which circumstances will the server decide to use a single
> transport session for these two different subscriptions?

If the "transport", "address", "port" are the same, then a single transport session can be used.  

During the reviews however, you and Kent have argued away both "port" and  "address" from being objects under the receiver.  So vendor specific augmentations will be needed to identify "address" and "port".  (Unless you are now ok with letting these objects back into the draft, just for the purposes of enable this a common receiver transport session identification.)  The other option is to have a future leafref augmented to ietf-netconf-server.yang as described above.

>  I can't see any text about this in the document.

I have added the following to the NETCONF-Notif document section on configured subscriptions:

"It is possible to have multiple configured subscriptions sharing a common transport to a single receiver.  The method of identifying that a receiver happens to be the same as used with another subscription is left up to implementers of this specification."

The text above can be changed if you are ok with adding "address" and "port" back into the draft.

> > > This said, "session sharing" can be acheived with the current
> > > design, as well as with the alternative design where the protocol is
> > > defined per receiver rather than per subscription.
> >
> > Agree.  Any issues with NETCONF transport multiplexing of subscriptions
> should be independent of the receiver YANG model.
> >
> > > But it won't be interoperable unless it is described.
> >
> > Likely NETCONF specific concerns would land in the NETCONF-notif.  I am
> happy to make any needed clarifications.
> 
> I think you will need specific text in both subscribed-notifications and in the
> transport drafts, if this is what you want to support.

I have added text to NETCONF-notif per above.

For subscribed-notifications, I have added the sentence to the first paragraph of the "configured subscriptions" section:

"Multiple configured subscriptions MUST be supportable over a single transport session."

> 
> /martin
> 
> 
> 
> >
> > Eric
> >
> > > /martin
> >