Re: [netconf] [yang-doctors] Yangdoctors last call review of draft-ietf-netconf-subscribed-notifications-21

Martin Bjorklund <mbj@tail-f.com> Fri, 25 January 2019 08:39 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 D358F12D4EF; Fri, 25 Jan 2019 00:39:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 jxVjmPQxEnE7; Fri, 25 Jan 2019 00:39:41 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0DF127133; Fri, 25 Jan 2019 00:39:41 -0800 (PST)
Received: from localhost (h-4-215.A165.priv.bahnhof.se [158.174.4.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 7361F1AE028C; Fri, 25 Jan 2019 09:39:38 +0100 (CET)
Date: Fri, 25 Jan 2019 09:39:38 +0100 (CET)
Message-Id: <20190125.093938.375156009332209799.mbj@tail-f.com>
To: evoit@cisco.com
Cc: andy@yumaworks.com, rrahman@cisco.com, alexander.clemm@huawei.com, yang-doctors@ietf.org, netconf@ietf.org, draft-ietf-netconf-subscribed-notifications.all@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <83b12adbb7234a84a56ac3ec00bb0673@XCH-RTP-013.cisco.com>
References: <9f0f48b7e17c40fab9a64b4a2488997e@XCH-RTP-013.cisco.com> <20190124.201415.264860524194078371.mbj@tail-f.com> <83b12adbb7234a84a56ac3ec00bb0673@XCH-RTP-013.cisco.com>
X-Mailer: Mew version 6.7 on Emacs 25.2 / 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/5SmdGwWhyYX47CbHUMikM92RYcw>
Subject: Re: [netconf] [yang-doctors] Yangdoctors last call review of draft-ietf-netconf-subscribed-notifications-21
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG 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: Fri, 25 Jan 2019 08:39:43 -0000

"Eric Voit (evoit)" <evoit@cisco.com>; wrote:
> > "Eric Voit (evoit)" <evoit@cisco.com>; wrote:
> > > > "Eric Voit (evoit)" <evoit@cisco.com>; wrote:
> > > > > > From: Martin Bjorklund, January 24, 2019 9:40 AM
> > > > > >
> > > > > > "Eric Voit (evoit)" <evoit@cisco.com>; wrote:
> > > > > > > > From: Martin Bjorklund, January 24, 2019 8:17 AM

[...]

> > > > > > > > Thinking some more, what is supposed to happen if the client on
> > > > > > > > the same session sends first an establish-subscription with dscp
> > > > > > > > 42, and then another establish-subscription with dscp 10?
> > > > > > >
> > > > > > > This would be allowed.
> > > > > >
> > > > > > On linux at least this is a sockopt, i.e., the option applies to the
> > > > > > socket, which means all packets on the session.  So how is this
> > > > > > supposed to be implemented if different messages on the session
> > > > > > should have different dscp values?
> > > > > > Or is the
> > > > > > idea that you send the msg, flush all data from ssh/tls to tcp, then
> > > > > > flush the tcp buffers (not that easy...)?
> > > > > >
> > > > > > Even if there's just one establish-subscription with a dscp value,
> > > > > > since it applies to the session it means that all normal rpcs on
> > > > > > this session will get the same dscp value.  It is not clear that
> > > > > > this is the intention?
> > 
> > Did you miss these questions?
> 
> With NETCONF, one DSCP will apply to single TCP session.  So there is no issue.

The problem is if a client sends two establish-subscriptions
with different values for dscp on the same session.  Or even if the
client sends one establish-subscription with som dscp value, then the
dscp will be applied to all packets from other rpcs as well.

... and even worse, with SSH channels you can have multiple NETCONF
session on the same TCP session, which means that the dscp value
applies to all packets in all NETCONF sessions sharing the same TCP
session.

I don't know what the right thing to do is.  Probably first agree that
this is in fact a problem, then maybe simply document this somehow.


> For RESTCONF, there is no requirement that there is a single TCP
> session between publisher and subscriber.

I agree that this is not a problem with RESTCONF, since there is no
multiplexing going on.  When the server accepts the SSE GET, it can
safely set the dscp value.

> Where there are different
> DSCPs requested, a different logical connection can be established
> should the publisher want to concurrently support several DSCPs.

I don't think is an issue, see above.


/martin