Re: [core] [Yot] YANG notification within CoMI

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 12 June 2018 01:21 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75F3A130EAC; Mon, 11 Jun 2018 18:21:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Ox3e0g3DL4UO; Mon, 11 Jun 2018 18:21:37 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D52A130DCF; Mon, 11 Jun 2018 18:21:36 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id B5F1920090; Mon, 11 Jun 2018 21:35:19 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 59D212F9D; Mon, 11 Jun 2018 21:18:40 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 57A042F98; Mon, 11 Jun 2018 21:18:40 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Michel Veillette <Michel.Veillette@trilliant.com>
cc: "Eric Voit (evoit)" <evoit@cisco.com>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, Peter van der Stok <stokcons@bbhmail.nl>, Andy Bierman <andy@yumaworks.com>, "yot@ietf.org" <yot@ietf.org>, Alexander Pelov <a@ackl.io>, Core <core@ietf.org>
In-Reply-To: <DM5PR06MB277742C8E8CEFD2443859CFF9A780@DM5PR06MB2777.namprd06.prod.outlook.com>
References: <DM5PR06MB2777CAB016D2789C4F1DD67F9A7B0@DM5PR06MB2777.namprd06.prod.outlook.com> <14497.1528550283@localhost> <DM5PR06MB277742C8E8CEFD2443859CFF9A780@DM5PR06MB2777.namprd06.prod.outlook.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Mon, 11 Jun 2018 21:18:40 -0400
Message-ID: <22940.1528766320@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/fs-NtrAGQBEq_AF76Qjh0tV7nAw>
Subject: Re: [core] [Yot] YANG notification within CoMI
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Jun 2018 01:21:41 -0000

Michel Veillette <Michel.Veillette@trilliant.com> wrote:
    > The main target of the CoMI protocol is network management. We
    > typically deploy this protocol between a Network Management System
    > (i.e. CoMI client) and hundreds of thousand or million(s) of
    > constrained network elements (i.e CoMI server). At that scale, the NMS
    > is implemented using a server cluster. The load balancer is used to
    > distribute the load of notifications between the different servers. The
    > load balancer also presents a stable IP address independent of the
    > currently available servers behind it.

yes, in IPv4 land, this is what you'd be forced to do.
In IPv6, it doesn't that much sense to me.

It seems that there many possible stateless ways of making what you describe
work without resorting to storing a bunch of state in a
single-point-of-failure Load balancer, and then having problems with keeping
context.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [