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

Martin Bjorklund <mbj@tail-f.com> Tue, 26 June 2018 18:42 UTC

Return-Path: <mbj@tail-f.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 703F91310FA for <netconf@ietfa.amsl.com>; Tue, 26 Jun 2018 11:42:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 x9k8SNrJRdGN for <netconf@ietfa.amsl.com>; Tue, 26 Jun 2018 11:42:43 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E77261310F8 for <netconf@ietf.org>; Tue, 26 Jun 2018 11:42:42 -0700 (PDT)
Received: from localhost (h-155-4-133-90.NA.cust.bahnhof.se [155.4.133.90]) by mail.tail-f.com (Postfix) with ESMTPSA id BB2191AE0311; Tue, 26 Jun 2018 20:42:40 +0200 (CEST)
Date: Tue, 26 Jun 2018 20:42:40 +0200 (CEST)
Message-Id: <20180626.204240.1818961627525784145.mbj@tail-f.com>
To: evoit@cisco.com
Cc: kwatsen@juniper.net, netconf@ietf.org, timjenki@cisco.com, alex@clemm.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <58867a306a1b4c2db94d98726a8fb40e@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>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/qCpBTQ3XV9f95X2X_ebXXxKD690>
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 18:42:46 -0000

"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.

> > 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?  I can't see any text about this in the document.

> > 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.



/martin



> 
> Eric
> 
> > /martin
>