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

Joe Marcus Clarke <jclarke@cisco.com> Tue, 17 September 2013 19:28 UTC

Return-Path: <jclarke@cisco.com>
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 53E7E11E855C for <i2rs@ietfa.amsl.com>; Tue, 17 Sep 2013 12:28:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 OsNQFdlY2I5X for <i2rs@ietfa.amsl.com>; Tue, 17 Sep 2013 12:28:37 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 39B0C11E8554 for <i2rs@ietf.org>; Tue, 17 Sep 2013 12:28:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1766; q=dns/txt; s=iport; t=1379446117; x=1380655717; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=NX5u7zLaffFngUPP4Q4qBNcH5lTuQpYJg5R2PoA9d5M=; b=jc8XzOuUmtx1DzdLHLHOsvxQ/ctEF3eHOybHncc8YRCFguORRHSvC/LY 5cNkcWTsHxpkhodb5lNxsMJ6NY3j8YfRI6NY4wwHYQMwXCedhK3WIfbI+ eyLcRl3PNDoT5MqzEdWzjYfFXOMMdwBGanoasDSd6IX6wSbeZHN9dRit7 M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgQFABGtOFKtJV2d/2dsb2JhbABXA4MHwi2BHxZ0giUBAQEEeA8CCw4EBgkWDwkDAgECAQkuDgYBDAYCAQGHf7pzBI4agTkXEYQNA5d7kXSDQCCBNQ
X-IronPort-AV: E=Sophos;i="4.90,925,1371081600"; d="scan'208";a="261090858"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 17 Sep 2013 19:28:34 +0000
Received: from dhcp-10-150-55-169.cisco.com (dhcp-10-150-55-169.cisco.com [10.150.55.169]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r8HJSYG2015354; Tue, 17 Sep 2013 19:28:34 GMT
Message-ID: <5238AD66.8060907@cisco.com>
Date: Tue, 17 Sep 2013 15:28:38 -0400
From: Joe Marcus Clarke <jclarke@cisco.com>
Organization: Cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: 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>
In-Reply-To: <20130915141145.GA66175@elstar.jacobs.jacobs-university.de>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [i2rs] Architecture Discussion 2: Persistence (ephemeral vs. permanent)
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.12
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, 17 Sep 2013 19:28:42 -0000

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.

Joe

-- 
Joe Marcus Clarke, CCIE #5384,         |          |
SCJP, SCSA, SCNA, SCSECA, VCP        |||||      |||||
Distinguished Services Engineer ..:|||||||||::|||||||||:..
Phone: +1 (919) 392-2867         c i s c o  S y s t e m s
Email: jclarke@cisco.com

----------------------------------------------------------------------------