Re: [i2rs] Architecture Discussion 2: Persistence (ephemeral vs. permanent)

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Tue, 17 September 2013 19:51 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A512711E854E for <i2rs@ietfa.amsl.com>; Tue, 17 Sep 2013 12:51:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.094
X-Spam-Level:
X-Spam-Status: No, score=-103.094 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRnYtyzQO6os for <i2rs@ietfa.amsl.com>; Tue, 17 Sep 2013 12:51:43 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3010311E856E for <i2rs@ietf.org>; Tue, 17 Sep 2013 12:51:42 -0700 (PDT)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D02C420BE5; Tue, 17 Sep 2013 21:51:41 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id VofwY5aShQGL; Tue, 17 Sep 2013 21:51:41 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 609D720BE0; Tue, 17 Sep 2013 21:51:41 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 2D3F52866B2F; Tue, 17 Sep 2013 21:51:32 +0200 (CEST)
Date: Tue, 17 Sep 2013 21:51:32 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Joe Marcus Clarke <jclarke@cisco.com>
Message-ID: <20130917195132.GA45071@elstar.local>
Mail-Followup-To: Joe Marcus Clarke <jclarke@cisco.com>, Scott Whyte <swhyte@google.com>, Alia Atlas <akatlas@gmail.com>, "i2rs@ietf.org" <i2rs@ietf.org>
References: <CAG4d1rebSFupD5gyd7KguA64oyu4LeCE_8RAbxtUuOm2ZOLQ2g@mail.gmail.com> <5231D77A.9050807@cisco.com> <CAG4d1rc+JzsGTOyjZst1mLuvwyaOUCsxYzXa6mJ_LYQexLJSHA@mail.gmail.com> <5231DC28.9060600@cisco.com> <CAG4d1rdmfjDSv5D2VwOBfFwzD+-NEtKNKFo5rWv8kXdgZAMWJw@mail.gmail.com> <5231E14E.5020605@cisco.com> <CAG4d1rc3vuh06SnqTWOta1AG=r8JPM5=00QvtUfZ9NGW+MQxTw@mail.gmail.com> <CAG=JvvjEQqdCE9PoPULUw7jEUXH1BnWCbFRjz231dzk5rQDWDA@mail.gmail.com> <20130915141145.GA66175@elstar.jacobs.jacobs-university.de> <5238AD66.8060907@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <5238AD66.8060907@cisco.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "i2rs@ietf.org" <i2rs@ietf.org>, Alia Atlas <akatlas@gmail.com>, Scott Whyte <swhyte@google.com>
Subject: Re: [i2rs] Architecture Discussion 2: Persistence (ephemeral vs. permanent)
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
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, 17 Sep 2013 19:51:48 -0000

On Tue, Sep 17, 2013 at 03:28:38PM -0400, Joe Marcus Clarke wrote:
> On 9/15/13 10:11 AM, Juergen Schoenwaelder wrote:
> > On Sat, Sep 14, 2013 at 08:41:03PM +0100, Scott Whyte wrote:
> >>
> >> I'm not sure I agree that a client is a direct subscriber, at least in the
> >> sense that brokers are very useful for scalability.  Using them I can
> >> design a system where each agent talks to N brokers, where N is reasonable
> >> for me (whether 2 or 20), and the broker-agent communication is independent
> >> of the broker-client communication.  It might be very nice to have the
> >> broker-agent communication be UDP and the broker-client communication be
> >> TCP for example, where I purposefully put the broker topologically close to
> >> the agents and the clients can be hierarchically distributed throughout the
> >> network.
> >>
> > 
> > I am not sure what exactly a 'broker' is. I did not see this term
> > defined in the architecture document nor in the problem statement
> > document. Whatever this 'broker' is precisely, is it needed for I2RS
> > 1.0 or something that may come along later?
> 
> It was not described in the architecture, but it is not an entirely
> foreign concept to I2RS discussions.  Nancy Cam-Winget brought it up
> during the IETF-87 session, and it is described in
> draft-camwinget-i2rs-pubsub-sec-00.  I realize this is not a WG document
> yet, and that the broker is not an element of the architecture yet, but
> a broker does represent a way of doing scalable pub-sub.

If brokers do impact data or information modeling decisions, I think
they should be discussed in the architecture explicitely. If the
architecture document then concludes that all that is needed to
support brokers is to be able to deal with multiple identities, fine.
Right now, it is kind of difficult for people not too deeply involved
to relate WG mailing list discussions to the content of WG documents.

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