Re: [i2rs] 2 week WG Adoption call (2/2 to 2/16/2015) - draft-voit-i2rs-pub-sub-requirements-00

"Eric Voit (evoit)" <evoit@cisco.com> Tue, 03 February 2015 17:34 UTC

Return-Path: <evoit@cisco.com>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 028711A1EFE for <i2rs@ietfa.amsl.com>; Tue, 3 Feb 2015 09:34:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 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_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 iZoBxPCv6nOz for <i2rs@ietfa.amsl.com>; Tue, 3 Feb 2015 09:34:10 -0800 (PST)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83CFC1A1BEF for <i2rs@ietf.org>; Tue, 3 Feb 2015 09:34:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3072; q=dns/txt; s=iport; t=1422984850; x=1424194450; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=bFB1z+RxECE8QtkCqWfo/C/Nz+3J17W1mkF+dgqoAF0=; b=Nu/aPdAA0BVyvVlqsTfiLytdPvUm00wtJUR7g10UjQVS97dndWcZR9Ob 3Jpt18C4cVNPu/4cIicIEFsbe9fMBqWHF60f6SgHjluyYeehVDAqzp3P9 k1ZyFPB+Fww5dn15JQ7lXHuqMtK0wsswzIkl429VTI4g9Nd7vNM7zWxek o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BCBQC6BdFU/5FdJa1XA4MGUlkExHsKhXECgR5DAQEBAQF9hAwBAQEDAQEBARodNAsFCQICAQgOAgUDCgMREBsMCyUCBAENBQgBEogKCA3WfwEBAQEBAQEBAQEBAQEBAQEBAQEBARcEjxwnIRAHEYMFgRMFjwyKPYsOgn2DPSKCAhwUgTxvAYEBQn4BAQE
X-IronPort-AV: E=Sophos;i="5.09,513,1418083200"; d="scan'208";a="120160988"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-2.cisco.com with ESMTP; 03 Feb 2015 17:34:10 +0000
Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t13HY9eg004422 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Feb 2015 17:34:09 GMT
Received: from xmb-aln-x11.cisco.com ([169.254.6.43]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Tue, 3 Feb 2015 11:34:09 -0600
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Susan Hares <shares@ndzh.com>
Thread-Topic: [i2rs] 2 week WG Adoption call (2/2 to 2/16/2015) - draft-voit-i2rs-pub-sub-requirements-00
Thread-Index: AQHQP4fv798VqLS8skKWuMMIXvsm75ze7FAA
Date: Tue, 03 Feb 2015 17:34:09 +0000
Message-ID: <EF64FF31F4C4384DBCE5D513A791C2B120B05AA1@xmb-aln-x11.cisco.com>
References: <011101d03f43$6b2b6870$41823950$@ndzh.com> <20150203080327.GA68276@elstar.local>
In-Reply-To: <20150203080327.GA68276@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.116.134.138]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/i2rs/N4OIPC0Di1Rjfm7IDvKi6nwc7bc>
Cc: 'Jeffrey Haas' <jhaas@pfrc.org>, "i2rs@ietf.org" <i2rs@ietf.org>
Subject: Re: [i2rs] 2 week WG Adoption call (2/2 to 2/16/2015) - draft-voit-i2rs-pub-sub-requirements-00
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/i2rs/>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Feb 2015 17:34:15 -0000

> From: i2rs on Behalf Of Juergen Schoenwaelder, February 03, 2015 3:03 AM
> 
> On Mon, Feb 02, 2015 at 06:53:16PM -0500, Susan Hares wrote:
> > This begins a 2 week WG Adoption call for:
> > draft-voit-i2rs-pub-sub-requirements-00  (2/2 to 2/16/2015).  You can
> > access the draft at:
> >
> > http://www.ietf.org/id/draft-voit-i2rs-pub-sub-requirements-00.txt
> >
> 
> I like to point out that some statements in the draft are either unclear or wrong.

As a "00" draft, I do expect that there will be changes needed.  Your feedback is certainly appreciated. 
 
>    o  limited support for pushed notification of changes.  (Currently
>       notifications are for configuration data only.  And even then,
>       subscription mechanisms for such notifications are undefined.)

The sub-bullet was intended to refine the "existing YANG technology ecosystem" paragraph above it.   That said, the word "undefined" will be changed in the next draft. More below.
 
> RFC 5277 defines a <create-subscription> mechanism.  RFC 6470 defines
> notifications that allow to track changes in a configuration datastore. So why is
> the subscription mechanisms undefined?

Netconf Event Notifications RFC5277 is useful, and everything possible from it should be incorporated in the ultimate technology solution.  But RFC5277 does not follow the Pub/Sub paradigm. It predates YANG.  In addition, a goal of this document is to frame requirements so as not to preclude support for additional transports beyond Netconf.  

Netconf Base Notifications RFC6470 is applicable for configuration info only.   The I2RS requirements mean we need to track many other things such as routing changes.

> But in more general terms, I am wondering what the scope of this work is. Is the
> goal to provide a mechanism similar to what we have already for 'config true'
> datastores for 'config false' datastores or is the goal to replace the existing
> mechanism with a new mechanism that will cover both 'config true' and 'config
> false' datastores?

The goal of this document is to aggregate and refine the I2RS requirements which highlight the needs of YANG Pub/Sub.  I believe there are several interesting requirements areas to explore here, including, 
- Dampening: confining the visibility of volatility into something digestible by the subscriber
- Liveliness: what to do if subsets of YANG subtrees can no longer be monitored or are stale
- Presentation: how do we bundle a set of discrete object notifications into a single publishable update for a Subscription

Mechanisms will follow requirements.

Eric
 
> /js
> 
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
> 
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs