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

"Eric Voit (evoit)" <evoit@cisco.com> Fri, 25 January 2019 15:14 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 44DAF130E6B; Fri, 25 Jan 2019 07:14:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -19.054
X-Spam-Level:
X-Spam-Status: No, score=-19.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 NVYuNYdKoJsi; Fri, 25 Jan 2019 07:14:38 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39C621294D0; Fri, 25 Jan 2019 07:14:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3217; q=dns/txt; s=iport; t=1548429278; x=1549638878; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TLwnB90xbGvWQ5AVhRNHt/TCOGMvKVbP0NWoZk3w2Qw=; b=ccykWoSa51EjNl4HtuP4SQzlfMdu1b1FPzNc1KdsOzq+zLlE6XdrE+NE zXsU9tNymT+r3IZ5K0R8GG/VBETBjPsF+qvdUi9jfgY94DEc9nnq1rDnn 7Gg9lj0fzQOUAf/ZQwIaNnBB5lfC2ni1PhN1WCttHTucrMaaEDWaS0RPH 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAACQJktc/49dJa1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgVopgWonCowRi3eCDZgHgXsLAQGEbAK?= =?us-ascii?q?DCiI0CQ0BAwEBAgEBAm0ohUoBAQEBAgE6PQIFCwIBCA4HAw0REDIlAgQOBQi?= =?us-ascii?q?CT4JFCKxTijCMQReBQD+EI4o/IgKJSIIgllAJAosFhxsgkiebHgIRFIEnHzi?= =?us-ascii?q?BVnAVgyeCJxcTjgoBQTGKD4EfAQE?=
X-IronPort-AV: E=Sophos;i="5.56,521,1539648000"; d="scan'208";a="231152222"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Jan 2019 15:14:37 +0000
Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x0PFEaBI010738 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 25 Jan 2019 15:14:37 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 25 Jan 2019 10:14:36 -0500
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.1395.000; Fri, 25 Jan 2019 10:14:36 -0500
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Martin Bjorklund <mbj@tail-f.com>
CC: "andy@yumaworks.com" <andy@yumaworks.com>, "Reshad Rahman (rrahman)" <rrahman@cisco.com>, "alexander.clemm@huawei.com" <alexander.clemm@huawei.com>, "yang-doctors@ietf.org" <yang-doctors@ietf.org>, "netconf@ietf.org" <netconf@ietf.org>, "draft-ietf-netconf-subscribed-notifications.all@ietf.org" <draft-ietf-netconf-subscribed-notifications.all@ietf.org>
Thread-Topic: [yang-doctors] Yangdoctors last call review of draft-ietf-netconf-subscribed-notifications-21
Thread-Index: AQHUrG6+nBjZ9hMl8U25QTRsXd0ZC6Ww36AggANDEICAARW3EIAAAXJggAU/bACAAWWKIIABCD+A///v5GCAAKn4AP//skVAgAGV2gD//60SYAANQ54AAApn7nD//7rBgIAATO5Q///xy4CAAB+zwIAAwVMA///xWjA=
Date: Fri, 25 Jan 2019 15:14:36 +0000
Message-ID: <adb990ccef2e4fa78d2ad7c12323617e@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> <20190125.093938.375156009332209799.mbj@tail-f.com>
In-Reply-To: <20190125.093938.375156009332209799.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.226]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.144, xch-rtp-004.cisco.com
X-Outbound-Node: rcdn-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/5idEW-kIHndpCeHZS8Ifye9-l5s>
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 15:14:40 -0000

> From: Martin Bjorklund, January 25, 2019 3:40 AM
> 
> "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.

I hadn't thought about multiple NETCONF SSH channels.  I agree something to guide developers is needed here.  The easiest fix is to recommend not supporting feature "dscp" with NETCONF.  (It shouldn't be absolutely prohibited as DSCP related RFC's such as RFC7657 embed text like "a single DSCP should be used for all packets in a TCP connection".)

Here is the text I suggest is put into draft-ietf-netconf-netconf-event-notifications, Section 5:

"The feature "dscp" SHOULD NOT be supported over NETCONF.  This will avoid the potential for out-of-order packet delivery of the set of all traffic within the TCP session."

With this text, a RESTCONF publisher can support the feature dscp.  And if someone attempts to use dscp with a NETCONF subscription to the same publisher, the error "dscp-unavailable" can be sent.

Eric 


...
> /martin