From tokatsu@cisco.com Sun Sep 1 18:35:20 2013 Return-Path: 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 EFC3011E81AD for ; Sun, 1 Sep 2013 18:35:18 -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 2EA+t77s-yK4 for ; Sun, 1 Sep 2013 18:35:13 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 3463A11E82CB for ; Sun, 1 Sep 2013 18:35:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3076; q=dns/txt; s=iport; t=1378085713; x=1379295313; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=bjZqmbmHHylvnezfD58v+7eerzW+M5eFToIu1HhGA7I=; b=FdODtIaWmqB/8LfhCgcAgN92LJwz/TUlRphwzaNANXDE9cBdCBxwV3fh 5JE6YQ3HAvU+sEaFRjmz2H9y3bbEyx6gKM4q9DHlY3nYHJ8uV8R5s5/Cl JFrdrrPct0xdEAUUtIgS88vAQJazDB865IrcW2jsvOCQKKERHiimDR+/2 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFAJ7qI1KtJV2Z/2dsb2JhbABbgweBBsB0gR4WdIIkAQEBBB0dPwwEAgEIEQQBAQsUCQcyFAkIAgQOBQiHerhxj04GKwcGgxeBAAOiMocpgyCCKg X-IronPort-AV: E=Sophos;i="4.89,1003,1367971200"; d="scan'208";a="254370235" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 02 Sep 2013 01:35:11 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r821ZBPM028519 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Sep 2013 01:35:11 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.8]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Sun, 1 Sep 2013 20:35:11 -0500 From: "Toru Okatsu (tokatsu)" To: Nitin Bahadur Thread-Topic: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-02 Thread-Index: AQHOotAdcmdi5mdIDUGwd5fuGYvUzJmpFiEQgAWGzwCAAxTdMA== Date: Mon, 2 Sep 2013 01:35:10 +0000 Message-ID: <2C754117643E1841B7DAA35BAC690E340862935E@xmb-rcd-x10.cisco.com> References: <2C754117643E1841B7DAA35BAC690E3408614668@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.141.57.126] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 01:35:20 -0000 Hi Nitin, Thanks for your response. I agree with you that the source ip address only case should be considered. I think the below expression is clearer to describe what the route is. ::=3D | | ( ) Thanks, Toru > -----Original Message----- > From: Nitin Bahadur [mailto:nitinb@juniper.net] > Sent: Saturday, August 31, 2013 6:25 AM > To: Toru Okatsu (tokatsu) > Cc: i2rs@ietf.org > Subject: Re: [i2rs] Call for WG Adoption: > draft-nitinb-i2rs-rib-info-model-02 >=20 > Hi Toru-san, >=20 > Thanks for your feedback. Some comments as below. >=20 >=20 > >In the section 6 which is about RIB grammar, it is better to change the > >definition of and to accommodate not only > >multicast routing but also source address base routing. > > > >Original: > > ::=3D [] > > ::=3D > > ::=3D > > > > > > ::=3D [] > > ::=3D > > ::=3D > > > > > >My comment: > > ::=3D [] > > ::=3D > > ::=3D > > ::=3D > > > > ::=3D [] > > ::=3D > > ::=3D > > ::=3D >=20 > If you are doing source-based routing, then you may or may not need the > destination-address. So ::=3D > [] is incorrect. >=20 > The below might be more correct: >=20 > ::=3D ( []) | > ( []) >=20 >=20 > >Another comment is a minor correction. In the section 7.2.3, > > should be . > > > >Original: > > ::=3D ( ) > > [( ) ... ] > > ::=3D ( ) > > [( )... ] > > > >My comment > > ::=3D ( ) > > [( ) ... ] > > ::=3D ( ) > > [( )... ] >=20 > This will be fixed in the next revision. >=20 > Thanks > Nitin >=20 From jmh@joelhalpern.com Mon Sep 2 00:15:45 2013 Return-Path: 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 B5AFB11E81CB for ; Mon, 2 Sep 2013 00:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, 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 R8amgNekDyHf for ; Mon, 2 Sep 2013 00:15:40 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 0F68011E81C8 for ; Mon, 2 Sep 2013 00:15:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id F378A1C0675; Mon, 2 Sep 2013 00:15:39 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [192.165.183.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 1E40E1C013E; Mon, 2 Sep 2013 00:15:38 -0700 (PDT) Message-ID: <52243B1A.6050102@joelhalpern.com> Date: Mon, 02 Sep 2013 03:15:38 -0400 From: "Joel M. Halpern" 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: "Toru Okatsu (tokatsu)" References: <2C754117643E1841B7DAA35BAC690E3408614668@xmb-rcd-x10.cisco.com> <2C754117643E1841B7DAA35BAC690E340862935E@xmb-rcd-x10.cisco.com> In-Reply-To: <2C754117643E1841B7DAA35BAC690E340862935E@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "i2rs@ietf.org" , Nitin Bahadur Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 07:15:46 -0000 There is one interesting complication if we are going to represent source address based routing in the RIB (which is not unreasoanble.) There are several different models of how to handle this. Not all devices will support all models. So how does the controller know how the device will interpret the entry? For context, there are some models which are source, then dest. There are some which are dest, then source. Also, while writing this, I wondered whether there is a semantic difference between source with no dest and source with 0/0 dest? If not, then is it not sufficient to require a dest, and allow 0/0? If there is a difference, what is it? Yours, Joel On 9/1/13 9:35 PM, Toru Okatsu (tokatsu) wrote: > Hi Nitin, > > Thanks for your response. > > I agree with you that the source ip address only case should be considered. > > I think the below expression is clearer to describe what the route is. > > ::= | | > ( ) > > Thanks, > > Toru >> -----Original Message----- >> From: Nitin Bahadur [mailto:nitinb@juniper.net] >> Sent: Saturday, August 31, 2013 6:25 AM >> To: Toru Okatsu (tokatsu) >> Cc: i2rs@ietf.org >> Subject: Re: [i2rs] Call for WG Adoption: >> draft-nitinb-i2rs-rib-info-model-02 >> >> Hi Toru-san, >> >> Thanks for your feedback. Some comments as below. >> >> >>> In the section 6 which is about RIB grammar, it is better to change the >>> definition of and to accommodate not only >>> multicast routing but also source address base routing. >>> >>> Original: >>> ::= [] >>> ::= >>> ::= >>> >>> >>> ::= [] >>> ::= >>> ::= >>> >>> >>> My comment: >>> ::= [] >>> ::= >>> ::= >>> ::= >>> >>> ::= [] >>> ::= >>> ::= >>> ::= >> >> If you are doing source-based routing, then you may or may not need the >> destination-address. So ::= >> [] is incorrect. >> >> The below might be more correct: >> >> ::= ( []) | >> ( []) >> >> >>> Another comment is a minor correction. In the section 7.2.3, >>> should be . >>> >>> Original: >>> ::= ( ) >>> [( ) ... ] >>> ::= ( ) >>> [( )... ] >>> >>> My comment >>> ::= ( ) >>> [( ) ... ] >>> ::= ( ) >>> [( )... ] >> >> This will be fixed in the next revision. >> >> Thanks >> Nitin >> > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From tokatsu@cisco.com Mon Sep 2 02:29:28 2013 Return-Path: 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 512F811E8125 for ; Mon, 2 Sep 2013 02:29:28 -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 K7YaAAE3buZ8 for ; Mon, 2 Sep 2013 02:29:23 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 6827611E81D1 for ; Mon, 2 Sep 2013 02:29:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5510; q=dns/txt; s=iport; t=1378114162; x=1379323762; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=SB/jYn814OEyT19re7wehe5VQ4pO37Lmo0xrgiEPfeg=; b=YFjRXRvm9WS6vKnBoHLUKwtToy1Psl8HuWY5jD48FqbubffID2X+WELY EoHCHv506iRWKt6woa22wN6ZQqKRVPOcuyDhTA46l+LGTd1WNoJlJ+jRo 9JkUHzrUMVKdFR/7pAy7rONf9liNng91yb+GNzGfudeysUDs78OWQK3D2 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAPNZJFKtJV2d/2dsb2JhbABagwc1UcB0gSEWdIIkAQEBBAEBARodNAsMBAIBCBEEAQEBChQJBycLFAkIAgQBDQUIh3oMuQ8Ej04GKwcGgxeBAAOiMocpgyCCKg X-IronPort-AV: E=Sophos;i="4.89,1006,1367971200"; d="scan'208";a="254525090" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 02 Sep 2013 09:29:22 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r829TKJD018342 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Sep 2013 09:29:21 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.8]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Mon, 2 Sep 2013 04:29:20 -0500 From: "Toru Okatsu (tokatsu)" To: "Joel M. Halpern" , Nitin Bahadur Thread-Topic: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-02 Thread-Index: AQHOotAdcmdi5mdIDUGwd5fuGYvUzJmpFiEQgAWGzwCAAxTdMIAAtNcA///Cr3A= Date: Mon, 2 Sep 2013 09:29:19 +0000 Message-ID: <2C754117643E1841B7DAA35BAC690E3408629979@xmb-rcd-x10.cisco.com> References: <2C754117643E1841B7DAA35BAC690E3408614668@xmb-rcd-x10.cisco.com> <2C754117643E1841B7DAA35BAC690E340862935E@xmb-rcd-x10.cisco.com> <52243B1A.6050102@joelhalpern.com> In-Reply-To: <52243B1A.6050102@joelhalpern.com> Accept-Language: en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.141.57.126] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 09:29:29 -0000 I cannot see the difference between source with no dest and source with 0/0= dest. Based on that, the below expression would be more correct. ::=3D 0/0 means the destination base routing. 0/0 means the source base routing the destination and sourc= e base routing. In terms of models to handle source base routing, the capability of being able to support it should be negotiated between the I2RS client and=20 the routing agent. Is it out of scope of I2RS about how the is= =20 interpreted by the routing agent? The application using the I2RS client should create data without ambiguity. Ex. 10.0.0.0/8 192.32.0.1/32 exists in the RIB. When 10.0.1.0/24 0/0 is added to the RIB, 10.0.1.0/24 192.32.0.1/32 should also be added. Thanks, Toru > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Monday, September 02, 2013 4:16 PM > To: Toru Okatsu (tokatsu) > Cc: Nitin Bahadur; i2rs@ietf.org > Subject: Re: [i2rs] Call for WG Adoption: > draft-nitinb-i2rs-rib-info-model-02 >=20 > There is one interesting complication if we are going to represent source > address based routing in the RIB (which is not unreasoanble.) There are > several different models of how to handle this. Not all devices will > support all models. So how does the controller know how the device will > interpret the entry? >=20 > For context, there are some models which are source, then dest. There ar= e > some which are dest, then source. >=20 > Also, while writing this, I wondered whether there is a semantic differen= ce > between source with no dest and source with 0/0 dest? If not, then is it > not sufficient to require a dest, and allow 0/0? If there is a differenc= e, > what is it? >=20 > Yours, > Joel >=20 > On 9/1/13 9:35 PM, Toru Okatsu (tokatsu) wrote: > > Hi Nitin, > > > > Thanks for your response. > > > > I agree with you that the source ip address only case should be conside= red. > > > > I think the below expression is clearer to describe what the route is. > > > > ::=3D | > | > > ( > ) > > > > Thanks, > > > > Toru > >> -----Original Message----- > >> From: Nitin Bahadur [mailto:nitinb@juniper.net] > >> Sent: Saturday, August 31, 2013 6:25 AM > >> To: Toru Okatsu (tokatsu) > >> Cc: i2rs@ietf.org > >> Subject: Re: [i2rs] Call for WG Adoption: > >> draft-nitinb-i2rs-rib-info-model-02 > >> > >> Hi Toru-san, > >> > >> Thanks for your feedback. Some comments as below. > >> > >> > >>> In the section 6 which is about RIB grammar, it is better to change > >>> the definition of and to accommodate not > >>> only multicast routing but also source address base routing. > >>> > >>> Original: > >>> ::=3D [] > >>> ::=3D > >>> ::=3D > >>> > >>> > >>> ::=3D [] > >>> ::=3D > >>> ::=3D > >>> > >>> > >>> My comment: > >>> ::=3D > [] > >>> ::=3D > >>> ::=3D > >>> ::=3D > >>> > >>> ::=3D > [] > >>> ::=3D > >>> ::=3D > >>> ::=3D > >> > >> If you are doing source-based routing, then you may or may not need > >> the destination-address. So ::=3D > >> [] is incorrect. > >> > >> The below might be more correct: > >> > >> ::=3D ( []= ) > | > >> ( > >> []) > >> > >> > >>> Another comment is a minor correction. In the section 7.2.3, > >>> should be . > >>> > >>> Original: > >>> ::=3D ( ) > >>> [( ) ... ] > >>> ::=3D ( ) > >>> [( )... ] > >>> > >>> My comment > >>> ::=3D ( ) > >>> [( ) ... ] > >>> ::=3D ( ) > >>> [( )... ] > >> > >> This will be fixed in the next revision. > >> > >> Thanks > >> Nitin > >> > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > From tokatsu@cisco.com Mon Sep 2 07:12:46 2013 Return-Path: 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 C6CDE21F9C16 for ; Mon, 2 Sep 2013 07:12:46 -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 y-rHglZEkC3H for ; Mon, 2 Sep 2013 07:12:42 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id D7DC421F9C0A for ; Mon, 2 Sep 2013 07:12:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6769; q=dns/txt; s=iport; t=1378131162; x=1379340762; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=s3du6Pg3yrgdfHseZoR1yDbc9iYm9A1nGkDxejeSD4g=; b=EKePMMRvflB+DBoiVdtSn5JWlSHSa5hvYwczm7mvFAB5O2MDHZfohPPc l/SsG9T9+4hMwzLQJFPk4mC0PKPt27eNMMtX7IaKt7hkQ5DXaK1qFD09A ulsm9zvpdR0Exyk9Lia8BcQCnvJ+yz7P5/rCPfAiwgJvYlExzgFuVTzrA U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAJObJFKtJV2a/2dsb2JhbABagwc1UcBmgScWdIIkAQEBBAEBARodNAsMBAIBCBEEAQEBChQJBycLFAkIAgQBDQUIh3oMuRgEjkaBCAYrBwaDF4EAA6IyhymDIIFxOQ X-IronPort-AV: E=Sophos;i="4.89,1007,1367971200"; d="scan'208";a="254609019" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 02 Sep 2013 14:12:41 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r82ECeBt019932 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Sep 2013 14:12:41 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.56]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Mon, 2 Sep 2013 09:12:41 -0500 From: "Toru Okatsu (tokatsu)" To: "Joel M. Halpern" , Nitin Bahadur Thread-Topic: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-02 Thread-Index: AQHOotAdcmdi5mdIDUGwd5fuGYvUzJmpFiEQgAWGzwCAAxTdMIAAtNcA///Cr3CAAFnZ0A== Date: Mon, 2 Sep 2013 14:12:40 +0000 Message-ID: <2C754117643E1841B7DAA35BAC690E340862F270@xmb-aln-x10.cisco.com> References: <2C754117643E1841B7DAA35BAC690E3408614668@xmb-rcd-x10.cisco.com> <2C754117643E1841B7DAA35BAC690E340862935E@xmb-rcd-x10.cisco.com> <52243B1A.6050102@joelhalpern.com> <2C754117643E1841B7DAA35BAC690E3408629979@xmb-rcd-x10.cisco.com> In-Reply-To: <2C754117643E1841B7DAA35BAC690E3408629979@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.230.125] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 14:12:46 -0000 I'd like to correct my previous e-mail. As RIB grammar the below expression would be better to understand. =20 ::=3D | | ( ) I still see no difference between source with no dest and source with=20 0/0 dest. But it is up to the implementation about which of them is used as data structure,=20 or ( 0/0 ) . Thanks, Toru > -----Original Message----- > From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of > Toru Okatsu (tokatsu) > Sent: Monday, September 02, 2013 6:29 PM > To: Joel M. Halpern; Nitin Bahadur > Cc: i2rs@ietf.org > Subject: Re: [i2rs] Call for WG Adoption: > draft-nitinb-i2rs-rib-info-model-02 >=20 > I cannot see the difference between source with no dest and source with > 0/0 dest. > Based on that, the below expression would be more correct. >=20 > ::=3D >=20 > 0/0 means the destination base routing. > 0/0 means the source base routing > the destination and > source base routing. >=20 > In terms of models to handle source base routing, the capability of being > able to support it should be negotiated between the I2RS client and the > routing agent. Is it out of scope of I2RS about how the is > interpreted by the routing agent? The application using the I2RS client > should create data without ambiguity. >=20 > Ex. 10.0.0.0/8 192.32.0.1/32 exists in the RIB. > When 10.0.1.0/24 0/0 is added to the RIB, > 10.0.1.0/24 192.32.0.1/32 should also be added. >=20 > Thanks, >=20 > Toru > > -----Original Message----- > > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > > Sent: Monday, September 02, 2013 4:16 PM > > To: Toru Okatsu (tokatsu) > > Cc: Nitin Bahadur; i2rs@ietf.org > > Subject: Re: [i2rs] Call for WG Adoption: > > draft-nitinb-i2rs-rib-info-model-02 > > > > There is one interesting complication if we are going to represent > > source address based routing in the RIB (which is not unreasoanble.) > > There are several different models of how to handle this. Not all > > devices will support all models. So how does the controller know how > > the device will interpret the entry? > > > > For context, there are some models which are source, then dest. There > > are some which are dest, then source. > > > > Also, while writing this, I wondered whether there is a semantic > > difference between source with no dest and source with 0/0 dest? If > > not, then is it not sufficient to require a dest, and allow 0/0? If > > there is a difference, what is it? > > > > Yours, > > Joel > > > > On 9/1/13 9:35 PM, Toru Okatsu (tokatsu) wrote: > > > Hi Nitin, > > > > > > Thanks for your response. > > > > > > I agree with you that the source ip address only case should be consi= dered. > > > > > > I think the below expression is clearer to describe what the route is= . > > > > > > ::=3D | > > > > > | > > > ( > > ) > > > > > > Thanks, > > > > > > Toru > > >> -----Original Message----- > > >> From: Nitin Bahadur [mailto:nitinb@juniper.net] > > >> Sent: Saturday, August 31, 2013 6:25 AM > > >> To: Toru Okatsu (tokatsu) > > >> Cc: i2rs@ietf.org > > >> Subject: Re: [i2rs] Call for WG Adoption: > > >> draft-nitinb-i2rs-rib-info-model-02 > > >> > > >> Hi Toru-san, > > >> > > >> Thanks for your feedback. Some comments as below. > > >> > > >> > > >>> In the section 6 which is about RIB grammar, it is better to > > >>> change the definition of and to > > >>> accommodate not only multicast routing but also source address base > routing. > > >>> > > >>> Original: > > >>> ::=3D > [] > > >>> ::=3D > > >>> ::=3D > > >>> > > >>> > > >>> ::=3D > [] > > >>> ::=3D > > >>> ::=3D > > >>> > > >>> > > >>> My comment: > > >>> ::=3D > > [] > > >>> ::=3D > > >>> ::=3D > > >>> ::=3D > > >>> > > >>> ::=3D > > [] > > >>> ::=3D > > >>> ::=3D > > >>> ::=3D > > >> > > >> If you are doing source-based routing, then you may or may not need > > >> the destination-address. So ::=3D > > >> [] is incorrect. > > >> > > >> The below might be more correct: > > >> > > >> ::=3D ( > > >> []) > > | > > >> ( > > >> []) > > >> > > >> > > >>> Another comment is a minor correction. In the section 7.2.3, > > >>> should be . > > >>> > > >>> Original: > > >>> ::=3D ( ) > > >>> [( > ) ... ] > > >>> ::=3D ( ) > > >>> [( )... ] > > >>> > > >>> My comment > > >>> ::=3D ( ) > > >>> [( > ) ... ] > > >>> ::=3D ( ) > > >>> [( )... ] > > >> > > >> This will be fixed in the next revision. > > >> > > >> Thanks > > >> Nitin > > >> > > > > > > _______________________________________________ > > > i2rs mailing list > > > i2rs@ietf.org > > > https://www.ietf.org/mailman/listinfo/i2rs > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From swhyte@google.com Wed Sep 4 10:02:21 2013 Return-Path: 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 71D0111E80EF for ; Wed, 4 Sep 2013 10:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 4aFsqhGAhrCH for ; Wed, 4 Sep 2013 10:02:20 -0700 (PDT) Received: from mail-pb0-x22c.google.com (mail-pb0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id E7DD921F9B26 for ; Wed, 4 Sep 2013 10:02:19 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id xa7so576652pbc.31 for ; Wed, 04 Sep 2013 10:02:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=VpHqXIQ07S/sBR+1rg1Jbc+Oqkg2mQ81PZlBHMII6Pc=; b=EaXMMOVGB17SAu0A8X8NkIymRq5PIjOpEXw39dPgoBfGnLwRgXjF6lCwZa24m0PHvz urtFls7dWYuGrQL1BZ+aUg8wilpe062P7vj84GTNkdeyrAzeCuxF0iqVxKI5Glo5NLaS 5wHcqZWbhv8yaZgK660q4ixrg3LFVbgSlqtvpCLB/r/Vg2pKwnIEylpWS6RlKaGKaVV4 p0aGDEmxO98hLkTCzJuEVmBfWNPel764qeB/XDKGhQ6ZzvA77zcVFJPGE3LVkrXo7aAi fIVPVuGK5YWrChMDVfkjhu+knRRv92YeLjqyVpw333X7+PrIy6eO4wIQ9VROfXy901W8 RPSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=VpHqXIQ07S/sBR+1rg1Jbc+Oqkg2mQ81PZlBHMII6Pc=; b=W4lWYuLvqBbZTnfYBzl4utn4BfBfh/HPRqZRmIN1bk4rYY3gtYYuQOb2FvgiAfM7ub lyqIo0l0KZBGUkKN9LgNyspkPvhVFcNWiiIQLYd5TQkEYdgAtKkqJh+sLTaV2UkUNQxl wTreU6RA1lG0El61Nm1kjmfYRPw536X9h5xOq8KNB55gi95zUdg5G1VMg7dm1Jq01Pfl O5L8YdzwYtzNuG/OM4WSFkl8wfgm1/n0E6b8zWdO2mrP2BAjfrrwjhs8UiF22Pjwa1Tn PukBbDj6Sdwtux8I8IiclicMlLRUTpSzrHnLMiMo6skxB1eJfOeev745yJjbcc1z2bs2 Qf0Q== X-Gm-Message-State: ALoCoQkY4mGErgYM2FtnN+vRA+z8n4DE8LkzvHnaDamDrHwl+BXaHAHNQaCnqFcj6Z5/hape3/KVxUxoOCPWwiNGJLhQL4+2ENuhi52IiSdh4eG+uV7iy+Ueog1JrfEr4JN4AKsIsMAZfE2CwLPQwkSmd9TctwSrh62WymHqOSsDCvYlZ7epUc9LagE4qYbv85SlaMbTdNPs X-Received: by 10.66.226.46 with SMTP id rp14mr4356893pac.133.1378314138019; Wed, 04 Sep 2013 10:02:18 -0700 (PDT) Received: from localhost ([2620:0:1000:3202:baac:6fff:fe7c:df72]) by mx.google.com with ESMTPSA id w6sm29907144pbt.32.1969.12.31.16.00.00 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 04 Sep 2013 10:02:16 -0700 (PDT) Date: Wed, 4 Sep 2013 10:02:15 -0700 From: Scott Whyte To: Alia Atlas Message-ID: <20130904170215.GB18914@google.com> References: <520BC349.5070206@joelhalpern.com> <520BE621.2090608@cisco.com> <520BFAB6.3040406@cisco.com> <20130815070648.GA8153@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "i2rs@ietf.org" , Carlos Pignataro , Joe Marcus Clarke , Juergen Schoenwaelder , Andy Bierman , "Joel M. Halpern" Subject: Re: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 17:02:22 -0000 On Thu, Aug 15, 2013 at 12:06:35PM -0400, Alia Atlas wrote: > Exactly - we need to give some real thought to the notifications and how > the filtering is set up. There's also a distinction between event > notifications and information streams, even though subscription may be > similar. > > For notifications, we have ideas such as: > register for a notification when state written by client X is changed > register for a notification when a particular state is changed > notify when route is installed in FIB > notify if interface utilization is over high-water threshold or under > low-water threshold > > For info streams, one could have: > subscribe to OSPF peer up/downs > subscribe to route changes (perhaps by protocol or within a prefix > range) > > There's the question of describing the desirable notifications and info > streams - and then figuring out how to support them in protocol mechanisms > (and the practicality for a real implementation). Alia, I would like to see a subscription for either information streams or notifications, perhaps a field in the subscription offer could determine whether its push or pull. Similarly, a single system should be able to provide data subscriptions with sub-second resolution and multi-hour resolution, by negotiating the frequency at a subscription start. In the architecture draft you speak of structured, filterable information and events. It would ideal if we can focus on the structure and filter mechanisms, and leave it up to an implementation to decide what to provide. In order to get as much data off of a node with as little impact as possible, we clearly need to require as little as possible in the way of complexity on the node. If the node can provide a list of things it publishes, with structure discoverable via introspection, filtering on the node should be as simple as only subscribing to what a consumer is interested in. Anything beyond that should be out of scope IMO and more complex filtering, authentication, reliability, etc lies in the pub/sub system deployed to collect the data. Apache Thrift has some interesting serialization solutions, in particular I think we should strongly consider decoupling transport from serialization, and providing a way to map in-memory data-structures to a negotiable wire format. -Scott > > Alia > > > On Thu, Aug 15, 2013 at 12:00 PM, Andy Bierman wrote: > > > Hi, > > > > Maybe it won't be that hard to automatically setup filters > > for common use-cases. E.g., if the 'inject' operation > > had parameters like 'notify-when-ready' and 'notify-if-bounced', > > then the server can send those notifications (just to that client) > > if the "inject" fails or gets deleted later, for the specific data entry. > > > > > > Andy > > > > > > > > > > On Thu, Aug 15, 2013 at 7:39 AM, Alia Atlas wrote: > > > Hi Andy, > > > > > > I meant that the traceability and syslog aspects are a 2nd order problem. > > > > > > I agree very strongly that notifications are a primary concern. That's > > how > > > clients learn > > > about network changes, changes affecting their state, etc. I believe > > that > > > we need a > > > sophisticated mechanism to filter and send just the relevant events to > > the > > > specific client. > > > Sending all notifications to all clients would be bad in terms of scaling > > > and security. > > > > > > I don't have a fixed number for the notifications per second. I'm > > curious > > > if others have thought > > > about it? > > > > > > Alia > > > > > > > > > > > > On Thu, Aug 15, 2013 at 10:31 AM, Andy Bierman > > wrote: > > >> > > >> Hi, > > >> > > >> We are going to run into several long-unsolved NM problems > > >> like "standardized log files". (Knowing that adding such a huge > > >> task to the charter would be a mistake is the difference between > > >> boiling an ocean or just a lake. ;-) > > >> > > >> Notifications may not be a 2nd order problem because the > > >> WG punted on the "I2RS broker" role. Now it is up to > > >> each I2RS Client to know that the RIB state it injected > > >> got replaced by a higher priority client, or know a higher > > >> priority entry was deleted and now maybe it can try again. > > >> > > >> IMO, the notification mechanism will need to be quite > > >> sophisticated to filter just the events relevant to a specific client. > > >> More likely all clients will each get all notifications, creating > > >> N fire-hoses of 'add' and 'delete' events. > > >> > > >> At the BoF, the metric "5000 updates a second" was mentioned > > >> as the answer to the question "what is fast-path?" How many > > >> notifications per second are reasonable for I2RS? > > >> > > >> > > >> Andy > > >> > > >> On Thu, Aug 15, 2013 at 7:10 AM, Alia Atlas wrote: > > >> > Juergen, > > >> > > > >> > Thanks for the useful information. I agree that a focus on > > traceability > > >> > is > > >> > not an initial primary goal, but Joe's point that syslog isn't > > >> > vendor-agnostic is a good one too. I'm not sure that I see a network > > >> > application doing automated troubleshooting and recovery - > > >> > but perhaps I'm insufficiently optimistic. > > >> > > > >> > Alia > > >> > > > >> > > > >> > On Thu, Aug 15, 2013 at 3:06 AM, Juergen Schoenwaelder > > >> > wrote: > > >> >> > > >> >> On Wed, Aug 14, 2013 at 05:46:30PM -0400, Joe Marcus Clarke wrote: > > >> >> > On 8/14/13 5:35 PM, Alia Atlas wrote: > > >> >> > > I can see having it in a file for displaying or sending - but > > >> >> > > actually > > >> >> > > having the I2RS agent crawl through it to report the data back??? > > >> >> > > > >> >> > A file/buffer is fine, but will lead to vendor-specific ways of > > >> >> > getting > > >> >> > at the data. As I read the architecture concerning information > > >> >> > collection, I thought this might be very useful information for a > > >> >> > Client > > >> >> > to collect from the Agent. > > >> >> > > > >> >> > I know Joel disagrees in favor of syslog. I think syslog is okay, > > >> >> > but > > >> >> > only if you're receiving messages since the beginning of time > > (i.e., > > >> >> > before a problem is identified). While I very well may be off base > > >> >> > here, having the a record of what Clients did what on a particular > > >> >> > Agent > > >> >> > in a vendor-agnostic way as information to be collected via I2RS > > >> >> > seemed > > >> >> > reasonable. > > >> >> > > >> >> Just for your information: RFC 5277 defines a NETCONF extension for > > >> >> notification delivery which supports the playback of event streams. > > >> >> This essentially allows implementations to buffer notifications > > (which > > >> >> might be syslog messages) for a certain time (or a certain volume) > > and > > >> >> one can request a replay of the notifications from a given start time > > >> >> until a certain stop time, optionally applying a filter to it. > > >> >> > > >> >> For debugging purposes, such a mechanism (buffering and selected and > > >> >> filtered playback) seems a reasonable solution that is also > > relatively > > >> >> easy to implement. If, however, complete accountability tracking is > > >> >> the goal, then you need to stream all notifications to an external > > >> >> server and you probably also need something like SYSLOG signatures > > >> >> (RFC 5848) to be able to prove that the notification log is complete > > >> >> etc. > > >> >> > > >> >> Personally, I think i2rs is likely better off with postponing work on > > >> >> event notification logging until the primary goals of i2rs have been > > >> >> met. For early implementors, protocols like SYSLOG likely are good > > >> >> enough. > > >> >> > > >> >> /js > > >> >> > > >> >> -- > > >> >> Juergen Schoenwaelder Jacobs University Bremen gGmbH > > >> >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > >> >> Fax: +49 421 200 3103 > > >> > > > >> > > > >> > > > >> > _______________________________________________ > > >> > i2rs mailing list > > >> > i2rs@ietf.org > > >> > https://www.ietf.org/mailman/listinfo/i2rs > > >> > > > > > > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nitinb@juniper.net Wed Sep 4 15:15:21 2013 Return-Path: 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 D81A621F9F97 for ; Wed, 4 Sep 2013 15:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.382 X-Spam-Level: X-Spam-Status: No, score=-3.382 tagged_above=-999 required=5 tests=[AWL=-0.783, BAYES_00=-2.599] 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 mvlo3SkyTWmE for ; Wed, 4 Sep 2013 15:15:16 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0188.outbound.messaging.microsoft.com [213.199.154.188]) by ietfa.amsl.com (Postfix) with ESMTP id 9131A21F9FBC for ; Wed, 4 Sep 2013 15:15:15 -0700 (PDT) Received: from mail155-db8-R.bigfish.com (10.174.8.242) by DB8EHSOBE022.bigfish.com (10.174.4.85) with Microsoft SMTP Server id 14.1.225.22; Wed, 4 Sep 2013 22:15:14 +0000 Received: from mail155-db8 (localhost [127.0.0.1]) by mail155-db8-R.bigfish.com (Postfix) with ESMTP id 71136120233; Wed, 4 Sep 2013 22:15:14 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: VPS-26(zzbb2dI98dI9371I542I1432I4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097h186068h8275bh8275dhz2fh2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh1155h) Received-SPF: pass (mail155-db8: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=nitinb@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(13464003)(24454002)(199002)(189002)(51704005)(164054003)(479174003)(377454003)(74366001)(74876001)(36756003)(51856001)(69226001)(83506001)(83072001)(74706001)(77096001)(56816003)(81542001)(79102001)(54356001)(81342001)(56776001)(76482001)(53806001)(54316002)(77982001)(59766001)(4396001)(31966008)(74662001)(47446002)(74502001)(47736001)(49866001)(47976001)(63696002)(50986001)(65816001)(81816001)(76176001)(81686001)(76786001)(76796001)(15975445006)(80022001)(19580395003)(46102001)(80976001)(19580405001)(83322001)(66066001); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB051; H:BL2PR05MB049.namprd05.prod.outlook.com; CLIP:66.129.224.54; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail155-db8 (localhost.localdomain [127.0.0.1]) by mail155-db8 (MessageSwitch) id 1378332912814098_6109; Wed, 4 Sep 2013 22:15:12 +0000 (UTC) Received: from DB8EHSMHS001.bigfish.com (unknown [10.174.8.225]) by mail155-db8.bigfish.com (Postfix) with ESMTP id B93623C0048; Wed, 4 Sep 2013 22:15:12 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by DB8EHSMHS001.bigfish.com (10.174.4.11) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 4 Sep 2013 22:15:12 +0000 Received: from BL2PR05MB051.namprd05.prod.outlook.com (10.255.228.151) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.353.4; Wed, 4 Sep 2013 22:15:05 +0000 Received: from BL2PR05MB049.namprd05.prod.outlook.com (10.255.228.144) by BL2PR05MB051.namprd05.prod.outlook.com (10.255.228.151) with Microsoft SMTP Server (TLS) id 15.0.745.25; Wed, 4 Sep 2013 22:15:04 +0000 Received: from BL2PR05MB049.namprd05.prod.outlook.com ([169.254.10.15]) by BL2PR05MB049.namprd05.prod.outlook.com ([169.254.10.47]) with mapi id 15.00.0745.000; Wed, 4 Sep 2013 22:15:04 +0000 From: Nitin Bahadur To: "Joel M. Halpern" , "Toru Okatsu (tokatsu)" Thread-Topic: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-02 Thread-Index: AQHOotAh8RvKRWKS5kiUGkwhgrfht5mpIJsAgASzJYCAA9/yAIAAXyAAgAOqo4A= Date: Wed, 4 Sep 2013 22:15:03 +0000 Message-ID: In-Reply-To: <52243B1A.6050102@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [66.129.224.54] x-forefront-prvs: 095972DF2F Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 22:15:22 -0000 The data-model has to correctly identify the source-address from the destination-address. Assuming a dest-addr will be followed by a src-address will not be good. I don't think there is a semantic difference between lack of a dest and a 0/0 dest. But requiring someone to specify a 0/0 dest even when there is no dest seems overkill. Just Like requiring a src-addr of 0/0 for a destination-address based route. Thanks Nitin Bahadur On 9/2/13 12:15 AM, "Joel M. Halpern" wrote: >There is one interesting complication if we are going to represent >source address based routing in the RIB (which is not unreasoanble.) >There are several different models of how to handle this. Not all >devices will support all models. So how does the controller know how >the device will interpret the entry? > >For context, there are some models which are source, then dest. There >are some which are dest, then source. > >Also, while writing this, I wondered whether there is a semantic >difference between source with no dest and source with 0/0 dest? If >not, then is it not sufficient to require a dest, and allow 0/0? If >there is a difference, what is it? > >Yours, >Joel > >On 9/1/13 9:35 PM, Toru Okatsu (tokatsu) wrote: >> Hi Nitin, >> >> Thanks for your response. >> >> I agree with you that the source ip address only case should be >>considered. >> >> I think the below expression is clearer to describe what the route is. >> >> ::=3D | = | >> ( ) >> >> Thanks, >> >> Toru >>> -----Original Message----- >>> From: Nitin Bahadur [mailto:nitinb@juniper.net] >>> Sent: Saturday, August 31, 2013 6:25 AM >>> To: Toru Okatsu (tokatsu) >>> Cc: i2rs@ietf.org >>> Subject: Re: [i2rs] Call for WG Adoption: >>> draft-nitinb-i2rs-rib-info-model-02 >>> >>> Hi Toru-san, >>> >>> Thanks for your feedback. Some comments as below. >>> >>> >>>> In the section 6 which is about RIB grammar, it is better to change >>>>the >>>> definition of and to accommodate not only >>>> multicast routing but also source address base routing. >>>> >>>> Original: >>>> ::=3D [] >>>> ::=3D >>>> ::=3D >>>> >>>> >>>> ::=3D [] >>>> ::=3D >>>> ::=3D >>>> >>>> >>>> My comment: >>>> ::=3D [] >>>> ::=3D >>>> ::=3D >>>> ::=3D >>>> >>>> ::=3D [= ] >>>> ::=3D >>>> ::=3D >>>> ::=3D >>> >>> If you are doing source-based routing, then you may or may not need the >>> destination-address. So ::=3D >>> [] is incorrect. >>> >>> The below might be more correct: >>> >>> ::=3D ( [])= | >>> ( []) >>> >>> >>>> Another comment is a minor correction. In the section 7.2.3, >>>> should be . >>>> >>>> Original: >>>> ::=3D ( ) >>>> [( ) ... ] >>>> ::=3D ( ) >>>> [( )... ] >>>> >>>> My comment >>>> ::=3D ( ) >>>> [( ) ... ] >>>> ::=3D ( ) >>>> [( )... ] >>> >>> This will be fixed in the next revision. >>> >>> Thanks >>> Nitin >>> >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> > > From jmh@joelhalpern.com Thu Sep 5 04:59:22 2013 Return-Path: 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 449B321E80B2 for ; Thu, 5 Sep 2013 04:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, 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 0ufzHEVX8FUl for ; Thu, 5 Sep 2013 04:59:17 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 4463E21E80ED for ; Thu, 5 Sep 2013 04:59:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id A34C81BD188D; Thu, 5 Sep 2013 04:59:07 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (c213-89-137-101.bredband.comhem.se [213.89.137.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 87F441BD1869; Thu, 5 Sep 2013 04:59:06 -0700 (PDT) Message-ID: <5228720B.10302@joelhalpern.com> Date: Thu, 05 Sep 2013 07:59:07 -0400 From: "Joel M. Halpern" 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: Nitin Bahadur References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Toru Okatsu \(tokatsu\)" , "i2rs@ietf.org" Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 11:59:22 -0000 I can live with both forms. I am concerned that having two ways to represent the same meaning is somewhat confusing and mildly error-prone. If you have a situation in which no source lookups are being performed, then you would want to omit the source field, rather than specifying it as 0/0. That clearly is a common case. Conversely, I do not think that there is any case where the lookup process itself would use the source address but not the destination address. Hence I think requiring that the destination be listed as 0/0 for routing entries that are to use both fields, but allow any destination, seems quite sensible. (For completeness of my thought, even if one has two default routes to the internet, for different source address prefixes, one still needs to perform the destination address check in order to handle local destinations. The converse is not true for sources in many environments.) Yours, Joel On 9/4/13 6:15 PM, Nitin Bahadur wrote: > > The data-model has to correctly identify the source-address from the > destination-address. > Assuming a dest-addr will be followed by a src-address will not be good. > > I don't think there is a semantic difference between lack of a dest and a > 0/0 dest. > But requiring someone to specify a 0/0 dest even when there is no dest > seems overkill. Just > Like requiring a src-addr of 0/0 for a destination-address based route. > > Thanks > Nitin Bahadur > > > > > > On 9/2/13 12:15 AM, "Joel M. Halpern" wrote: > >> There is one interesting complication if we are going to represent >> source address based routing in the RIB (which is not unreasoanble.) >> There are several different models of how to handle this. Not all >> devices will support all models. So how does the controller know how >> the device will interpret the entry? >> >> For context, there are some models which are source, then dest. There >> are some which are dest, then source. >> >> Also, while writing this, I wondered whether there is a semantic >> difference between source with no dest and source with 0/0 dest? If >> not, then is it not sufficient to require a dest, and allow 0/0? If >> there is a difference, what is it? >> >> Yours, >> Joel >> >> On 9/1/13 9:35 PM, Toru Okatsu (tokatsu) wrote: >>> Hi Nitin, >>> >>> Thanks for your response. >>> >>> I agree with you that the source ip address only case should be >>> considered. >>> >>> I think the below expression is clearer to describe what the route is. >>> >>> ::= | | >>> ( ) >>> >>> Thanks, >>> >>> Toru >>>> -----Original Message----- >>>> From: Nitin Bahadur [mailto:nitinb@juniper.net] >>>> Sent: Saturday, August 31, 2013 6:25 AM >>>> To: Toru Okatsu (tokatsu) >>>> Cc: i2rs@ietf.org >>>> Subject: Re: [i2rs] Call for WG Adoption: >>>> draft-nitinb-i2rs-rib-info-model-02 >>>> >>>> Hi Toru-san, >>>> >>>> Thanks for your feedback. Some comments as below. >>>> >>>> >>>>> In the section 6 which is about RIB grammar, it is better to change >>>>> the >>>>> definition of and to accommodate not only >>>>> multicast routing but also source address base routing. >>>>> >>>>> Original: >>>>> ::= [] >>>>> ::= >>>>> ::= >>>>> >>>>> >>>>> ::= [] >>>>> ::= >>>>> ::= >>>>> >>>>> >>>>> My comment: >>>>> ::= [] >>>>> ::= >>>>> ::= >>>>> ::= >>>>> >>>>> ::= [] >>>>> ::= >>>>> ::= >>>>> ::= >>>> >>>> If you are doing source-based routing, then you may or may not need the >>>> destination-address. So ::= >>>> [] is incorrect. >>>> >>>> The below might be more correct: >>>> >>>> ::= ( []) | >>>> ( []) >>>> >>>> >>>>> Another comment is a minor correction. In the section 7.2.3, >>>>> should be . >>>>> >>>>> Original: >>>>> ::= ( ) >>>>> [( ) ... ] >>>>> ::= ( ) >>>>> [( )... ] >>>>> >>>>> My comment >>>>> ::= ( ) >>>>> [( ) ... ] >>>>> ::= ( ) >>>>> [( )... ] >>>> >>>> This will be fixed in the next revision. >>>> >>>> Thanks >>>> Nitin >>>> >>> >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>> >> >> > > > From russw@riw.us Thu Sep 5 16:02:56 2013 Return-Path: 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 270F111E8116 for ; Thu, 5 Sep 2013 16:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599] 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 5KcYj9hCo4Ra for ; Thu, 5 Sep 2013 16:02:46 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 68E3C11E80ED for ; Thu, 5 Sep 2013 16:02:46 -0700 (PDT) Received: from cpe-098-122-147-095.nc.res.rr.com ([98.122.147.95] helo=RussPC) by da31.namelessnet.net with esmtpa (Exim 4.80.1) (envelope-from ) id 1VHiZY-0003pW-St; Thu, 05 Sep 2013 16:02:45 -0700 From: "Russ White" To: "'Joel M. Halpern'" , "'Nitin Bahadur'" References: <5228720B.10302@joelhalpern.com> In-Reply-To: <5228720B.10302@joelhalpern.com> Date: Thu, 5 Sep 2013 19:02:55 -0400 Message-ID: <028601ceaa8c$11090430$331b0c90$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHxqzYulWTKhrwAlRS0e7dP9DN6dwLa5glImVrqFUA= Content-Language: en-us X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Cc: "'Toru Okatsu \(tokatsu\)'" , i2rs@ietf.org Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 23:02:57 -0000 > Conversely, I do not think that there is any case where the lookup process > itself would use the source address but not the destination address. Hence I Just to double check --multicast forwarding based on the source group? Another place this might exist is unicast RPF checks on an inbound line card (in situations where the destination address isn't looked up until further along in the switching process). Neither of these might be valid; just throwing them out there to make certain we've covered all the bases. :-) Russ From jmh@joelhalpern.com Fri Sep 6 01:58:54 2013 Return-Path: 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 E138D21F9D3A for ; Fri, 6 Sep 2013 01:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, 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 DvlSDMz2jWIR for ; Fri, 6 Sep 2013 01:58:50 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 2530621F8578 for ; Fri, 6 Sep 2013 01:58:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 12CB81BC4428; Fri, 6 Sep 2013 01:58:50 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [192.165.183.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 0EB4D1BC441A; Fri, 6 Sep 2013 01:58:48 -0700 (PDT) Message-ID: <5229994B.8070405@joelhalpern.com> Date: Fri, 06 Sep 2013 04:58:51 -0400 From: "Joel M. Halpern" 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: Russ White References: <5228720B.10302@joelhalpern.com> <028601ceaa8c$11090430$331b0c90$@riw.us> In-Reply-To: <028601ceaa8c$11090430$331b0c90$@riw.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'Toru Okatsu \(tokatsu\)'" , i2rs@ietf.org, 'Nitin Bahadur' Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 08:58:55 -0000 While multicast is an interesting case, as far as I know it requires a dest lookup as well as a source lookup. Yours, Joel On 9/5/13 7:02 PM, Russ White wrote: > >> Conversely, I do not think that there is any case where the lookup process >> itself would use the source address but not the destination address. > Hence I > > Just to double check --multicast forwarding based on the source group? > Another place this might exist is unicast RPF checks on an inbound line card > (in situations where the destination address isn't looked up until further > along in the switching process). Neither of these might be valid; just > throwing them out there to make certain we've covered all the bases. > > :-) > > Russ > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From sriganeshkini@gmail.com Mon Sep 9 13:27:52 2013 Return-Path: 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 312B121E80C6 for ; Mon, 9 Sep 2013 13:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 KJ81xs30bmLi for ; Mon, 9 Sep 2013 13:27:50 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 58CD411E813A for ; Mon, 9 Sep 2013 13:27:46 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id kl13so6746727pab.34 for ; Mon, 09 Sep 2013 13:27:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Znm6MpOAaDz4jyAkkm7c4brhHCM97O9fBRmgBHDmOow=; b=Z6v+8FbRZm1EzejmolDuDJu/W27OlZxP25u07sbxyhAN9bokPOc2mMPLu1bnBBxURh /zE6bSu1/upcPa/hPChSR+1Zscf9n9yJMyDkePKTw4V9k3kjjRqawTRIjx1p9haOpTPW DefEBgoWADMrANDIMu3xaaTfjlWFAS7OB113lbOJLxNTtHaXvrEemhemdVVb3ASXIyI0 scIcUFUqW7wp5XDUghoiJAorzovR38u7o5BsuZEPFhQhCZopXNeEqZIO7EoS00Nn4caS PXiuVGsfcYu86DZlCNZOs0RuE9tSAVLbhGy1epynxfRocMhc7AJh9n5hAb16wWvYzbKV me/Q== X-Received: by 10.68.253.227 with SMTP id ad3mr3841834pbd.189.1378758462818; Mon, 09 Sep 2013 13:27:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.70.13.129 with HTTP; Mon, 9 Sep 2013 13:27:12 -0700 (PDT) In-Reply-To: References: From: Sri Date: Mon, 9 Sep 2013 13:27:12 -0700 Message-ID: To: Edward Crabbe Content-Type: multipart/alternative; boundary=047d7b1630d16852f704e5f93800 Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 20:27:52 -0000 --047d7b1630d16852f704e5f93800 Content-Type: text/plain; charset=UTF-8 Support as co-author. On Mon, Aug 26, 2013 at 7:49 PM, Edward Crabbe wrote: > Hey all; > > Nitin published an updated version of his RIB info model draft, available > at: > > http://tools.ietf.org/html/draft-nitinb-i2rs-rib-info-model-02 > > Please review this draft and comment on whether it should be adopted > as an I2RS document. > > This WG call for adoption will finish on September 9th. > > best, > -ed > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --047d7b1630d16852f704e5f93800 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Support as co-author.
=

On Mon, Aug 26, 2013 at 7:49 PM, Edward = Crabbe <edc@google.com> wrote:
Hey all;

Nitin published an updated version of his RIB info model draft, available a= t:

http://tools.ietf.org/html/draft-nitinb-i2rs-rib-info-mod= el-02

Please review this draft and comment on whether it should be adopted
as an I2RS document.

This WG call for adoption will finish on September 9th.

best,
=C2=A0 =C2=A0-ed
_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs

--047d7b1630d16852f704e5f93800-- From jmedved@cisco.com Mon Sep 9 13:59:55 2013 Return-Path: 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 3741221E80DA for ; Mon, 9 Sep 2013 13:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 2n-GHdT4O+sW for ; Mon, 9 Sep 2013 13:59:39 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id BE8D811E80F8 for ; Mon, 9 Sep 2013 13:59:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4157; q=dns/txt; s=iport; t=1378760373; x=1379969973; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=epB/Dwn5d/DPe03klAPct9R6/EOcLLLH/1Aie6/A5LY=; b=jsMXYr53bYjsAnmN8zUZoi4P8cO6vFGUD/kFroY0dy3DXKa4+2y1lzSL v3TgjYDqqjzaurDNMbhsTe1NReazlP8Pl6AehUPlDfQhq3FmlIbVbcQrS a78z6gvY+Ys+yjBpklfUsFjNidMMucP0TFudv/fdA4Z5EHj1B8n4SGkvk I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjkFADc2LlKtJXHB/2dsb2JhbABbgkNEOFG5Xog+gSYWdIIlAQEBBAEBARpRCxIBCAQKAwMBAgsdKAYLFAkIAgQOBQiHaAMPDLl4DYkgjRKCPSANBAeDHYEAA5YMgxiJDoF6hS+DIIIq X-IronPort-AV: E=Sophos;i="4.90,873,1371081600"; d="scan'208,217";a="254512390" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 09 Sep 2013 20:59:33 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r89KxXiR019331 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Sep 2013 20:59:33 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.59]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Mon, 9 Sep 2013 15:59:32 -0500 From: "Jan Medved (jmedved)" To: Edward Crabbe Thread-Topic: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-02 Thread-Index: AQHOrZsqfi72BdU2aES+z9jOiXyEApm9wjYA Date: Mon, 9 Sep 2013 20:59:31 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.27.7.167] Content-Type: multipart/alternative; boundary="_000_ACC8AB2D98C05F4E9FBDA092017D97FC172FDDF6xmbalnx10ciscoc_" MIME-Version: 1.0 Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 20:59:55 -0000 --_000_ACC8AB2D98C05F4E9FBDA092017D97FC172FDDF6xmbalnx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support as co-author. From: Sri > Date: Monday, September 9, 2013 1:27 PM To: Edward Crabbe > Cc: "i2rs@ietf.org" > Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-= 02 Support as co-author. On Mon, Aug 26, 2013 at 7:49 PM, Edward Crabbe > wrote: Hey all; Nitin published an updated version of his RIB info model draft, available a= t: http://tools.ietf.org/html/draft-nitinb-i2rs-rib-info-model-02 Please review this draft and comment on whether it should be adopted as an I2RS document. This WG call for adoption will finish on September 9th. best, -ed _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs --_000_ACC8AB2D98C05F4E9FBDA092017D97FC172FDDF6xmbalnx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <1C440BCA7F84444C9FF50BDE54BA2B07@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Support as co-author.

From: Sri <sriganeshkini@gmail.com>
Date: Monday, September 9, 2013 1:2= 7 PM
To: Edward Crabbe <edc@google.com>
Cc: "i2rs@ietf.org" <i2rs@i= etf.org>
Subject: Re: [i2rs] Call for WG Ado= ption: draft-nitinb-i2rs-rib-info-model-02

Support as co-author.


On Mon, Aug 26, 2013 at 7:49 PM, Edward Crabbe <= span dir=3D"ltr"> <edc@google.com&= gt; wrote:
Hey all;

Nitin published an updated version of his RIB info model draft, available a= t:

http://tools.ietf.org/html/draft-nitinb-i2rs-rib-info-mod= el-02

Please review this draft and comment on whether it should be adopted
as an I2RS document.

This WG call for adoption will finish on September 9th.

best,
   -ed
_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs

 --_000_ACC8AB2D98C05F4E9FBDA092017D97FC172FDDF6xmbalnx10ciscoc_-- From jrmitche@puck.nether.net Mon Sep 9 14:27:31 2013 Return-Path: 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 0F92711E8164 for ; Mon, 9 Sep 2013 14:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 NY94f88D-BfZ for ; Mon, 9 Sep 2013 14:27:16 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 0067511E80E9 for ; Mon, 9 Sep 2013 14:27:08 -0700 (PDT) Received: from puck.nether.net (localhost [127.0.0.1]) by puck.nether.net (8.14.7/8.14.5) with ESMTP id r89LR4CC006238; Mon, 9 Sep 2013 17:27:04 -0400 Received: (from jrmitche@localhost) by puck.nether.net (8.14.7/8.14.7/Submit) id r89LR3ls006228; Mon, 9 Sep 2013 17:27:03 -0400 Date: Mon, 9 Sep 2013 17:27:03 -0400 From: Jon Mitchell To: Edward Crabbe Message-ID: <20130909212703.GB29570@puck.nether.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.1 (puck.nether.net [127.0.0.1]); Mon, 09 Sep 2013 17:27:04 -0400 (EDT) Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 21:27:31 -0000 On 26/08/13 19:49 -0700, Edward Crabbe wrote: > Hey all; > > Nitin published an updated version of his RIB info model draft, available at: > > http://tools.ietf.org/html/draft-nitinb-i2rs-rib-info-model-02 > > Please review this draft and comment on whether it should be adopted > as an I2RS document. > > This WG call for adoption will finish on September 9th. Support. -Jon From jeff.tantsura@ericsson.com Mon Sep 9 14:31:22 2013 Return-Path: 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 D01FB21F92B5 for ; Mon, 9 Sep 2013 14:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 7PBMRdcAQjbz for ; Mon, 9 Sep 2013 14:31:15 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3B28421F9CC0 for ; Mon, 9 Sep 2013 14:30:51 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-cc-522e3e0af8a9 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 32.04.09414.A0E3E225; Mon, 9 Sep 2013 23:30:50 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0328.009; Mon, 9 Sep 2013 17:30:39 -0400 From: Jeff Tantsura To: Edward Crabbe Thread-Topic: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-02 Thread-Index: AQHOotAbQLSm7mH4f06R3KUFBb62Mpm+M1sA//+cXgA= Date: Mon, 9 Sep 2013 21:30:39 +0000 Message-ID: <60DEDD93F5E54B4AB55647B8B6C7483991B9ED@eusaamb109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_60DEDD93F5E54B4AB55647B8B6C7483991B9EDeusaamb109ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyuXRPrC6XnV6QwdljkhYPF29kt1g34wOL A5PHgk2lHkuW/GQKYIrisklJzcksSy3St0vgyvi46ABzQaNExZTD/1kaGLtEuxg5OSQETCQm LdrIDGGLSVy4t56ti5GLQ0jgKKPE3h1zGSGcZYwSE3qWsoBUsQkYSPz/dhzMFhFQkljQfh2s m1lAWWLiy/1A3RwcwgK+Eku+SUCUBEj8P9rNDmFbScxf+R2slUVAReLC1QNgNq+At8TDeV2M IDanQKDE2SW72UBsRqCDvp9awwQxXlzi1pP5TBCHCkgs2XMe6mhRiZeP/7GC2KICehJtx86w Q8SVJZY82c8C0Zsv8frEB0aIXYISJ2c+YZnAKDoLydhZSMpmISmDiOtILNj9iQ3C1pZYtvA1 M4x95sBjqF5riSuzZzIjq1nAyLGKkaO0OLUsN93IYBMjMNaOSbDp7mDc89LyEKM0B4uSOO8q vTOBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhjNrt96NXX+3yU68vnTmbguKxw5JjuNc5Jz u6DJqYN//MQfqry9rrTp+ffLjWsKNFvyi4O+71iT2mN41KL669PL2/N3OfR4dTx9nxPJXXBt ZtPjDbeypDsUryq8fh3bl/uRZ9/fEx+tv/a2cXV8qy+LlvUs9LhpWHzhWPWj0O6rkyJ0Zq8T Op+sxFKckWioxVxUnAgAwXb6doMCAAA= Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 21:31:22 -0000 --_000_60DEDD93F5E54B4AB55647B8B6C7483991B9EDeusaamb109ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes/support Cheers, Jeff On Mon, Aug 26, 2013 at 7:49 PM, Edward Crabbe > wrote: Hey all; Nitin published an updated version of his RIB info model draft, available a= t: http://tools.ietf.org/html/draft-nitinb-i2rs-rib-info-model-02 Please review this draft and comment on whether it should be adopted as an I2RS document. This WG call for adoption will finish on September 9th. best, -ed _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs --_000_60DEDD93F5E54B4AB55647B8B6C7483991B9EDeusaamb109ericsso_ Content-Type: text/html; charset="us-ascii" Content-ID: <63E97C9D77A7F34584F3356B594A131E@ericsson.com> Content-Transfer-Encoding: quoted-printable
Yes/support

Cheers,
Jeff

On Mon, Aug 26, 2013 at 7:49 PM, Edward Crabbe <= span dir=3D"ltr"> <edc@google.com&= gt; wrote:
Hey all;

Nitin published an updated version of his RIB info model draft, available a= t:

http://tools.ietf.org/html/draft-nitinb-i2rs-rib-info-mod= el-02

Please review this draft and comment on whether it should be adopted
as an I2RS document.

This WG call for adoption will finish on September 9th.

best,
   -ed
_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs

 --_000_60DEDD93F5E54B4AB55647B8B6C7483991B9EDeusaamb109ericsso_-- From lufang@cisco.com Mon Sep 9 14:47:10 2013 Return-Path: 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 6C7AC21F9DF1 for ; Mon, 9 Sep 2013 14:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Y0-ohBSn2ChU for ; Mon, 9 Sep 2013 14:47:05 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 6748C21F862B for ; Mon, 9 Sep 2013 14:47:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2616; q=dns/txt; s=iport; t=1378763225; x=1379972825; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=+nD7KVTpLpL8Tt0y6PWEgKYvMN1szWl40betuhwUvpQ=; b=fWSK+2tOebZx0nATVq01IdZyMzG3lH5VhSSt/Jsyq4QTDx/zNgy2MN1x S+n1ezT29y3yhQ92sp6EajTOe2cyIxBmXNqQQPSzstcnNBOU+C+yh8tGe 65TwpWU7g78365BJLMb+vl7T8N5g1P+FRfENqDWZjYivtj/ytIWTqRWcx E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioGAC1BLlKtJXG8/2dsb2JhbABbgkNEOFG5YIg+gScWdIInAQQBAQEaUQsSAQgEAQkUHS4LFBECBA4FCId6DMMgjzotBAeDHYEAA5kkiQ6HKYMggio X-IronPort-AV: E=Sophos;i="4.90,873,1371081600"; d="scan'208,217";a="257524567" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 09 Sep 2013 21:47:02 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r89Ll2d4027919 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Sep 2013 21:47:02 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.157]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Mon, 9 Sep 2013 16:47:02 -0500 From: "Luyuan Fang (lufang)" To: Edward Crabbe Thread-Topic: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-02 Thread-Index: AQHOotAcT1Wk7ekvOE2C9djbG939E5m+RB8A///TPIA= Date: Mon, 9 Sep 2013 21:47:01 +0000 Message-ID: <0DB8F45437AB844CBB5102F807A0AD93105093E4@xmb-rcd-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.21.125.25] Content-Type: multipart/alternative; boundary="_000_0DB8F45437AB844CBB5102F807A0AD93105093E4xmbrcdx03ciscoc_" MIME-Version: 1.0 Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 21:47:10 -0000 --_000_0DB8F45437AB844CBB5102F807A0AD93105093E4xmbrcdx03ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, support. Luyuan On Mon, Aug 26, 2013 at 7:49 PM, Edward Crabbe > wrote: Hey all; Nitin published an updated version of his RIB info model draft, available a= t: http://tools.ietf.org/html/draft-nitinb-i2rs-rib-info-model-02 Please review this draft and comment on whether it should be adopted as an I2RS document. This WG call for adoption will finish on September 9th. best, -ed _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs --_000_0DB8F45437AB844CBB5102F807A0AD93105093E4xmbrcdx03ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <2924D03F6BD42B4AA67B59755E301DCA@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Yes, support.
Luyuan

On Mon, Aug 26, 2013 at 7:49 PM, Edward Crabbe <= span dir=3D"ltr"> <edc@google.com&= gt; wrote:
Hey all;

Nitin published an updated version of his RIB info model draft, available a= t:

http://tools.ietf.org/html/draft-nitinb-i2rs-rib-info-mod= el-02

Please review this draft and comment on whether it should be adopted
as an I2RS document.

This WG call for adoption will finish on September 9th.

best,
   -ed
_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs

 --_000_0DB8F45437AB844CBB5102F807A0AD93105093E4xmbrcdx03ciscoc_-- From alex@cisco.com Mon Sep 9 14:51:28 2013 Return-Path: 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 C99FC21E8169 for ; Mon, 9 Sep 2013 14:51:28 -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 7qeaQx4owa0W for ; Mon, 9 Sep 2013 14:51:24 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 016E621E80CB for ; Mon, 9 Sep 2013 14:51:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=787; q=dns/txt; s=iport; t=1378763484; x=1379973084; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=rdsiy2sLENtmUIqDbT5hU4g8UZSoYjgeCBe6TpPXNeA=; b=EnPxjX22C+cqEN/cRTjK4tBL2FOcNw++mVcUgTuavqP8izoJAqv2FJxU FDGIqVQfJXFMTOryaxNRuFxUZUf9SuaJ/49aIZ3nkIGKYGUfgw4mtElkT 2lNPOA8RjK+G5Q9iXwj/qknbQz/AgUS0+YA4M1GxIvnschNeTZ8iCHFoC 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoIFAKZBLlKtJXHB/2dsb2JhbABbgwc4UYJjvzuBJxZ0giUBAQEEAQEBGh00FwQCAQgOAwQBAQsUCQcnCxQJCAIEARIIh3oMwyGPOjgGgxeBAAOZJIkOhymDIIIq X-IronPort-AV: E=Sophos;i="4.90,873,1371081600"; d="scan'208";a="257499997" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 09 Sep 2013 21:51:23 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r89LpNKG021615 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Sep 2013 21:51:23 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.100]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Mon, 9 Sep 2013 16:51:23 -0500 From: "Alexander Clemm (alex)" To: Edward Crabbe , "i2rs@ietf.org" Thread-Topic: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-02 Thread-Index: AQHOotAcMu1Er/NUQkWnvnbO9Pwvbpm+B2rg Date: Mon, 9 Sep 2013 21:51:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.204.85] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 21:51:28 -0000 I think this is clearly needed and I support its adoption.=20 --- Alex -----Original Message----- From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of Edw= ard Crabbe Sent: Monday, August 26, 2013 7:49 PM To: i2rs@ietf.org Subject: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-02 Hey all; Nitin published an updated version of his RIB info model draft, available a= t: http://tools.ietf.org/html/draft-nitinb-i2rs-rib-info-model-02 Please review this draft and comment on whether it should be adopted as an = I2RS document. This WG call for adoption will finish on September 9th. best, -ed _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From ramk@Brocade.com Mon Sep 9 16:05:59 2013 Return-Path: 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 8B89011E8189 for ; Mon, 9 Sep 2013 16:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.264 X-Spam-Level: X-Spam-Status: No, score=-3.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] 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 9xTZSd01+VB3 for ; Mon, 9 Sep 2013 16:05:54 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by ietfa.amsl.com (Postfix) with ESMTP id BCC4511E80DC for ; Mon, 9 Sep 2013 16:05:54 -0700 (PDT) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id r89N5pBE021113; Mon, 9 Sep 2013 16:05:52 -0700 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 1esn7pg549-6 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 09 Sep 2013 16:05:52 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by hq1wp-exchub02.corp.brocade.com (10.70.38.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 9 Sep 2013 16:05:52 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Mon, 9 Sep 2013 16:05:47 -0700 From: ramki Krishnan To: Edward Crabbe Date: Mon, 9 Sep 2013 16:05:28 -0700 Thread-Topic: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-02 Thread-Index: Ac6tmyhreiMp6rSHQayzk4Tyn4zHTgAFdWVg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7634EB63EFD984A978DFB46EA5174F2BFFE854329HQ1EXCH01corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-09_07:2013-09-09, 2013-09-09, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1309090143 Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 23:05:59 -0000 --_000_C7634EB63EFD984A978DFB46EA5174F2BFFE854329HQ1EXCH01corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VwcG9ydC4NClRoYW5rcywNClJhbWtpDQpPbiBNb24sIEF1ZyAyNiwgMjAxMyBhdCA3OjQ5IFBN LCBFZHdhcmQgQ3JhYmJlIDxlZGNAZ29vZ2xlLmNvbTxtYWlsdG86ZWRjQGdvb2dsZS5jb20+PiB3 cm90ZToNCkhleSBhbGw7DQoNCk5pdGluIHB1Ymxpc2hlZCBhbiB1cGRhdGVkIHZlcnNpb24gb2Yg aGlzIFJJQiBpbmZvIG1vZGVsIGRyYWZ0LCBhdmFpbGFibGUgYXQ6DQoNCmh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LW5pdGluYi1pMnJzLXJpYi1pbmZvLW1vZGVsLTAyDQoNClBsZWFz ZSByZXZpZXcgdGhpcyBkcmFmdCBhbmQgY29tbWVudCBvbiB3aGV0aGVyIGl0IHNob3VsZCBiZSBh ZG9wdGVkDQphcyBhbiBJMlJTIGRvY3VtZW50Lg0KDQpUaGlzIFdHIGNhbGwgZm9yIGFkb3B0aW9u IHdpbGwgZmluaXNoIG9uIFNlcHRlbWJlciA5dGguDQoNCmJlc3QsDQogICAtZWQNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQppMnJzIG1haWxpbmcgbGlz dA0KaTJyc0BpZXRmLm9yZzxtYWlsdG86aTJyc0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vaTJycw0KDQo= --_000_C7634EB63EFD984A978DFB46EA5174F2BFFE854329HQ1EXCH01corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KDQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+DQo8IS0tDQog LyogRm9udCBEZWZpbml0aW9ucyAqLw0KIEBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJy aWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0K IC8qIFN0eWxlIERlZmluaXRpb25zICovDQogcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2 Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0K YTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5N c29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVy cGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGlu Ow0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuU2VjdGlvbjENCgl7cGFn ZTpTZWN0aW9uMTt9DQotLT4NCjwvc3R5bGU+DQo8IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KICA8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCiA8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQoNCjxib2R5IGxhbmc9RU4tVVMgbGlu az1ibHVlIHZsaW5rPXB1cnBsZT4NCg0KPGRpdiBjbGFzcz1TZWN0aW9uMT4NCg0KPGRpdj4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7DQpmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPlN1cHBvcnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDsNCmZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7DQpmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PlJhbWtpPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWw+T24gTW9uLCBBdWcgMjYsIDIwMTMgYXQgNzo0OSBQTSwgRWR3YXJkIENyYWJiZSAmbHQ7PGEN CmhyZWY9Im1haWx0bzplZGNAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmVkY0Bnb29nbGUu Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD5I ZXkgYWxsOzxicj4NCjxicj4NCk5pdGluIHB1Ymxpc2hlZCBhbiB1cGRhdGVkIHZlcnNpb24gb2Yg aGlzIFJJQiBpbmZvIG1vZGVsIGRyYWZ0LCBhdmFpbGFibGUgYXQ6PGJyPg0KPGJyPg0KPGEgaHJl Zj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbml0aW5iLWkycnMtcmliLWluZm8t bW9kZWwtMDIiDQp0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtbml0aW5iLWkycnMtcmliLWluZm8tbW9kZWwtMDI8L2E+PGJyPg0KPGJyPg0KUGxlYXNlIHJl dmlldyB0aGlzIGRyYWZ0IGFuZCBjb21tZW50IG9uIHdoZXRoZXIgaXQgc2hvdWxkIGJlIGFkb3B0 ZWQ8YnI+DQphcyBhbiBJMlJTIGRvY3VtZW50Ljxicj4NCjxicj4NClRoaXMgV0cgY2FsbCBmb3Ig YWRvcHRpb24gd2lsbCBmaW5pc2ggb24gU2VwdGVtYmVyIDl0aC48YnI+DQo8YnI+DQpiZXN0LDxi cj4NCiZuYnNwOyAmbmJzcDstZWQ8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCmkycnMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp bHRvOmkycnNAaWV0Zi5vcmciPmkycnNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMnJzIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMnJzPC9hPjxvOnA+PC9vOnA+PC9w Pg0KDQo8L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K DQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjwvYm9keT4NCg0KPC9odG1sPg0K --_000_C7634EB63EFD984A978DFB46EA5174F2BFFE854329HQ1EXCH01corp_-- From russw@riw.us Mon Sep 9 18:14:28 2013 Return-Path: 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 AA16221E8063 for ; Mon, 9 Sep 2013 18:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] 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 TTmzyleU88E3 for ; Mon, 9 Sep 2013 18:14:16 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id CCD2611E80E8 for ; Mon, 9 Sep 2013 18:14:16 -0700 (PDT) Received: from [12.207.21.2] (helo=RussPC) by da31.namelessnet.net with esmtpa (Exim 4.80.1) (envelope-from ) id 1VJCX1-0003gV-EC; Mon, 09 Sep 2013 18:14:15 -0700 From: "Russ White" To: "'ramki Krishnan'" , "'Edward Crabbe'" References: In-Reply-To: Date: Mon, 9 Sep 2013 21:14:13 -0400 Message-ID: <011801ceadc3$120b4700$3621d500$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQE7m+34H5kcsDuoNgXueN+5shweLAJw14+hAkTgPIiavqB6EA== Content-Language: en-us X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Cc: i2rs@ietf.org Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 01:14:28 -0000 Support. Russ > -----Original Message----- > From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf = Of > ramki Krishnan > Sent: Monday, September 09, 2013 7:05 PM > To: Edward Crabbe > Cc: i2rs@ietf.org > Subject: Re: [i2rs] Call for WG Adoption: = draft-nitinb-i2rs-rib-info-model-02 >=20 > Support. >=20 > Thanks, >=20 > Ramki >=20 > On Mon, Aug 26, 2013 at 7:49 PM, Edward Crabbe > wrote: >=20 > Hey all; >=20 > Nitin published an updated version of his RIB info model draft, = available at: >=20 > http://tools.ietf.org/html/draft-nitinb-i2rs-rib-info-model-02 >=20 > Please review this draft and comment on whether it should be adopted = as an > I2RS document. >=20 > This WG call for adoption will finish on September 9th. >=20 > best, > -ed > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs >=20 >=20 From luayjalil@gmail.com Mon Sep 9 19:28:42 2013 Return-Path: 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 07A4E11E8130 for ; Mon, 9 Sep 2013 19:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 Ziq6gNd9RbhW for ; Mon, 9 Sep 2013 19:28:40 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 14E5C11E810A for ; Mon, 9 Sep 2013 19:28:40 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id es8so6718768obc.0 for ; Mon, 09 Sep 2013 19:28:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=npcgMVuKWYiUXWhBGraw9ntC8q9vAi2bh97IrtC/L9M=; b=V4vCkqjfwls/VeeSGILwORCPGVY4f6wKTlpvoZPpy4NHP3HGqvyQeg4ECeggK3YIZX rfgcp6mBrMza0gTACk9uJTrzKNpmsXa5kELSarq80qCeJIegHFCPYjisD011YTXpK2n9 8o0M3osHCD2LiOaVqPWb+RYIE4IHBGYVJYemirFmzwPqVl6BUPAoCmscPBv04up/S2A/ 1VUYWa1LnsnMlBK1aio7OAdmq2jQO2LgwbYuuSNhN3wultk9CogmVYKCjosWuWFY/g7W CRuYycL8KDxi2UNIFLk5FyRBFk8AC4hEt3HgwiE5xKcpxNe7pGEwJe+QJNDryiSsAarO iUbw== MIME-Version: 1.0 X-Received: by 10.60.131.41 with SMTP id oj9mr4199517oeb.40.1378780119630; Mon, 09 Sep 2013 19:28:39 -0700 (PDT) Received: by 10.182.148.39 with HTTP; Mon, 9 Sep 2013 19:28:39 -0700 (PDT) In-Reply-To: References: Date: Mon, 9 Sep 2013 21:28:39 -0500 Message-ID: From: Luay Jalil To: Edward Crabbe Content-Type: multipart/alternative; boundary=089e013c701a410d3204e5fe43f3 Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 02:28:42 -0000 --089e013c701a410d3204e5fe43f3 Content-Type: text/plain; charset=ISO-8859-1 Support Luay On Monday, August 26, 2013, Edward Crabbe wrote: > Hey all; > > Nitin published an updated version of his RIB info model draft, available > at: > > http://tools.ietf.org/html/draft-nitinb-i2rs-rib-info-model-02 > > Please review this draft and comment on whether it should be adopted > as an I2RS document. > > This WG call for adoption will finish on September 9th. > > best, > -ed > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > -- *Luay* --089e013c701a410d3204e5fe43f3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Support

Luay

On Monday, August 26, 2= 013, Edward Crabbe wrote:
Hey all;

Nitin published an updated version of his RIB info model draft, available a= t:

http://tools.ietf.org/html/draft-nitinb-i2rs-rib-info-mod= el-02

Please review this draft and comment on whether it should be adopted
as an I2RS document.

This WG call for adoption will finish on September 9th.

best,
=A0 =A0-ed
_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs


--
Luay
--089e013c701a410d3204e5fe43f3-- From akatlas@gmail.com Thu Sep 12 07:44:40 2013 Return-Path: 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 E4A5A11E8242 for ; Thu, 12 Sep 2013 07:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 72pA0wxlSeBA for ; Thu, 12 Sep 2013 07:44:40 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id ABAE711E8236 for ; Thu, 12 Sep 2013 07:44:39 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id tp5so1165643ieb.26 for ; Thu, 12 Sep 2013 07:44:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=pwcxzhzhlaDTjpUofMtf3sBSAfVrRbseSrqzv2za2/0=; b=xx6X8m2IsmDtPJBwDLzYYV66Wbd1tRlImHOuVBq/hrwKuyDOMF24Zh44rIho06QXTS LusWUELd8gW2UP1plotcmmJaYPUhVcf2eKqveMnkrAbgMhjp9tE0mOIMDxLuxtY3q2qb PJu8WV5MD++M6AE9/w/0+i2CeWASZfRINUKDh8A3tp5W3RnVGVVT4E+gPE7c1qepuzoL NF7UYDekpYbvpBPWxGyhP5rMls2oS1MaZhRzYd66/LQz6d9OyHscbo8c61qlcapnjNzA oimV1dqGWoMSMs1M2GjA+ZBXUOlVbIhe7jsiyqA8dTVe9584nbGdzMMK1EV/t0zM6kqq 0MMA== MIME-Version: 1.0 X-Received: by 10.50.102.99 with SMTP id fn3mr13344729igb.5.1378997079315; Thu, 12 Sep 2013 07:44:39 -0700 (PDT) Received: by 10.64.13.145 with HTTP; Thu, 12 Sep 2013 07:44:39 -0700 (PDT) Date: Thu, 12 Sep 2013 10:44:39 -0400 Message-ID: From: Alia Atlas To: "i2rs@ietf.org" Content-Type: multipart/alternative; boundary=e89a8ffbae3f0f20ef04e630c79d Subject: [i2rs] Architecture Discussion 1: Indirect Interactions X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 14:44:41 -0000 --e89a8ffbae3f0f20ef04e630c79d Content-Type: text/plain; charset=ISO-8859-1 In draft-ietf-i2rs-architecture-00 Sec 1.2, at the end it says: " In addition it must be noted that there may be indirect interactions between write operations. Detection and avoidance of such interactions is outside the scope of the I2RS work and is left to agent design and implementation for now. [[Editor's note: This topic needs more discussion in the working group.]]" I would like to start that discussion now. I would like to conclude the discussion by determining what changes are needed in the architecture draft - whether those are removing the Editor's note or something more. Personally, I think that detecting arbitrary indirect interactions is very hard and better done outside of the I2RS data-models and protocol. However, there might be capabilities that could assist in mitigating those interactions. For instance, the idea of a "write x if y=z" operation was suggested. Please comment away! Alia (WG-chair hat off) --e89a8ffbae3f0f20ef04e630c79d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
In draft-ietf-i2rs-architecture-00 Sec 1.2, at the end it = says:

"= In addition it must be noted that there= may be indirect interactions
   between write operations.  =
Detection and avoidance of such
   interactions is outside the scope of the I2RS work and is left to
   agent design and implementation for now.  [[Editor's note: This topi=
c
   needs more discussion in the working group.]]"

I would like to st=
art that discussion now. =A0I would like to conclude the discussion
by determining what changes are needed=
 in the architecture draft - whether those
are removing the Edito=
r's note or something more.



Personally, I t=
hink that detecting arbitrary indirect interactions is very hard and=

better done outside of the I2RS dat=
a-models and protocol. =A0However, there might
be capabilities tha=
t could assist in mitigating those interactions. =A0For instance, the
idea of a "write=
 x if y=3Dz" operation was suggested.=A0

Please comment away!

Alia (WG-chair hat off)

--e89a8ffbae3f0f20ef04e630c79d-- From akatlas@gmail.com Thu Sep 12 07:48:16 2013 Return-Path: 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 B5E2C11E821E for ; Thu, 12 Sep 2013 07:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 4W9BrIXVqwrI for ; Thu, 12 Sep 2013 07:48:04 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 4992911E81B1 for ; Thu, 12 Sep 2013 07:48:04 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id tp5so1175611ieb.26 for ; Thu, 12 Sep 2013 07:47:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=VOlvRHlQp0xl/tszFEIfLTPbKhHCVQMHUt82svclpiQ=; b=GGUcjHZwnCuPdZUheHxQtOKhvxtNq3I59GA/zT6IR2NZnTNskvGcpdMC4rFPCaxCTF PHC1jpHpmPLbFoZz7Hzo+VG1p4PJl5cEOiKnUYuUaSYuzWuahrF6F1357VpcyHO0p73Q M3Y2L3Tjo/MpBS1afWEdaDokJHJlX6caJfAYCKWV9RXX25mSu+0whKR/QbIwhQl9XSnF QTo9I7Erxft8TlIWA3AcoUbkoVub0Lj7ImMRW7QQuQb17LvNxS92+eVfFB+gDkduZ1h4 C2y9stdXm6qh1jM5ThKnIhkMN77z8lbUAgkLfUIB3xXTz6qdCipB7BmjJPTdyxypGfOu Qa9A== MIME-Version: 1.0 X-Received: by 10.50.22.105 with SMTP id c9mr13734180igf.36.1378997272591; Thu, 12 Sep 2013 07:47:52 -0700 (PDT) Received: by 10.64.13.145 with HTTP; Thu, 12 Sep 2013 07:47:52 -0700 (PDT) Date: Thu, 12 Sep 2013 10:47:52 -0400 Message-ID: From: Alia Atlas To: "i2rs@ietf.org" Content-Type: multipart/alternative; boundary=047d7b10cd83944b5204e630d22a Subject: [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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 14:48:16 -0000 --047d7b10cd83944b5204e630d22a Content-Type: text/plain; charset=ISO-8859-1 In draft-ietf-i2rs-architecture-00 Sec 5.2, it says: "The I2RS Agent will not attempt to retain or reapply state across routing element reboot. Determination of whether state still applies depends heavily on the causes of reboots, and reapplication is at least as likely to cause problems as it is to provide for correct operation. [[Editor's note: This topics needs more discussion in the working group.]]" I would like to start that discussion and rapidly conclude it with the needed changes (removal of the Editor's note or otherwise). My personal impression is that simplifying to just ephemeral state was viewed as a good idea. What do others think? Does anyone strongly disagree? Thanks, Alia (WG-chair hat off) --047d7b10cd83944b5204e630d22a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
In draft-ietf-= i2rs-architecture-00 Sec 5.2, it says:

"The I2RS Agent will not at= tempt to retain or reapply state across
   routing element reboot.  De=
termination of whether state still applies
   depends heavily on the causes of reboots, and reapplication is at
   least as likely to cause problems as it is to provide for correct
   operation.  [[Editor's note: This topics needs more discussion in th=
e
   working group.]]"

I would like to start that disc=
ussion and rapidly conclude it with the needed
changes (removal of the Editor's note or o=
therwise).

My personal impression is that simplifyin=
g to just ephemeral state was
viewed as a good idea.  What d=
o others think?  Does anyone strongly
disagree?

Thanks,
Alia (WG-chair hat off)
--047d7b10cd83944b5204e630d22a-- From akatlas@gmail.com Thu Sep 12 07:52:25 2013 Return-Path: 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 27A4F11E821E for ; Thu, 12 Sep 2013 07:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 I61ow+tWY2pP for ; Thu, 12 Sep 2013 07:52:24 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 9D51A11E8214 for ; Thu, 12 Sep 2013 07:52:24 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id at1so1259269iec.2 for ; Thu, 12 Sep 2013 07:52:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=8FApT/4BC6scnT/UpEQwUy6Im2ctNU5AIMmgEbj0fPI=; b=FKI81bq9pG4t8+JzCy68YzBLG+wPZVVyR/KqINwtw8NJ34LU4SGLzKohHAJ+0OggjF FF4O0868glakvGK7j5gg5KmIKzibt4sceRa7fGBbB/sEKkk9gM5zbU2T6CIagAQpLfml egAEUpUDbGTNQnFwno69YH7Gek4XQPlOlPj2zQmSTisngy5vG0BRnTJ6/qKJcz49jh8e 0zvPqI82b1sonELrMG8b3qD0E3zHr/7ShwReXYlNf8Y3EY3CcYAIJ0u3VqTpbw3cC5OD ymLEoWWuvBIkMqy+PnqJNWk200fItHw+brtEf9nLAbFTkeKBRXuSn+8qRAgWKMzMy2vX WOzw== MIME-Version: 1.0 X-Received: by 10.50.102.99 with SMTP id fn3mr13354519igb.5.1378997544184; Thu, 12 Sep 2013 07:52:24 -0700 (PDT) Received: by 10.64.13.145 with HTTP; Thu, 12 Sep 2013 07:52:24 -0700 (PDT) Date: Thu, 12 Sep 2013 10:52:24 -0400 Message-ID: From: Alia Atlas To: "i2rs@ietf.org" Content-Type: multipart/alternative; boundary=e89a8ffbae3fc47a1404e630e28f Subject: [i2rs] Architecture Discussion 3: Operations are Immediate and continuing X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 14:52:25 -0000 --e89a8ffbae3fc47a1404e630e28f Content-Type: text/plain; charset=ISO-8859-1 In draft-ietf-i2rs-architecture-00 Sec. 5.2.1: " Given that the complexity of possible conditions is very large, and that some conditions may even cross network element boundaries, clearly some degree of handling must be provided on the I2RS client. As such, in this architecture it is assumed that all the complexity associated with this should be left to the I2RS client. This architectural view does mean that reliability of the communication path between the I2RS client and I2RS agent is critical. [[Editor's note: This requires more discussion in the working group.]]" I would like to start this discussion and conclude it rapidly. Personally, I have heard that this is a good simplification. Removing the ability to specify the start-time and end-time of an operation adds complexity and we don't clearly have use-cases that need it. Does anyone have a different perspective? Thanks, Alia (WG-chair hat off) --e89a8ffbae3fc47a1404e630e28f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
In draft-ietf-= i2rs-architecture-00 Sec. 5.2.1:

" Given that the complexity of = possible conditions is very large, and
   that some conditions may ev=
en cross network element boundaries,
   clearly some degree of handling must be provided on the I2RS client.
   As such, in this architecture it is assumed that all the complexity
   associated with this should be left to the I2RS client.  This
   architectural view does mean that reliability of the communication
   path between the I2RS client and I2RS agent is critical.  [[Editor's
   note: This requires more discussion in the working group.]]"=


I would like to start this disc=
ussion and conclude it rapidly.



Personally, I hav=
e heard that this is a good simplification.  Removing the=A0
ability to specify the start-ti= me and end-time of an operation adds complexity
and we don't clearly have use-cases that =
need it.  Does anyone have a different
perspective?



Thanks,
Alia (WG-chair hat off)

--e89a8ffbae3fc47a1404e630e28f-- From akatlas@gmail.com Thu Sep 12 07:56:02 2013 Return-Path: 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 B89C111E8238 for ; Thu, 12 Sep 2013 07:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 KM4o0XnbFJxF for ; Thu, 12 Sep 2013 07:55:59 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 33EFE11E8214 for ; Thu, 12 Sep 2013 07:55:38 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id to1so11848063ieb.37 for ; Thu, 12 Sep 2013 07:55:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=KHgfB0UbawxTAThycCrjVQT4JydNHbvItAiI+6UGdtc=; b=u9lar6B6G0xZcg2QkWIzUaUYVeS0n+M5+L2lolBMhnMKEt6RUHsDJqEbdWuYDL8ZRZ tOzuSrwqs5+BX7TKQSyZBYu+HgRkGqwf2S+4LpOj0+cKAmUjqzJd7V1e9WxN5Eitke/F QhdVeATLIJmtJD+NdBVBxW529CCoQfyy1xF7DUVtCfVt1N+Qc/lYeOrRgxM3xVZhYZ09 b9Fy2ivIWk6QZPbxZWNgRB3Q9kNcIw11hAkC86C9TlRTiklo3MwCphcIt0gcUqnNj/yK DA40RKLl2UwhYUpkdZMtIkFaHgvmmXEu9VpPQzTyzaoNIrUrWuKUvZRNhRbd/uB8K2L3 +R3A== MIME-Version: 1.0 X-Received: by 10.50.102.99 with SMTP id fn3mr13358596igb.5.1378997738176; Thu, 12 Sep 2013 07:55:38 -0700 (PDT) Received: by 10.64.13.145 with HTTP; Thu, 12 Sep 2013 07:55:38 -0700 (PDT) Date: Thu, 12 Sep 2013 10:55:38 -0400 Message-ID: From: Alia Atlas To: "i2rs@ietf.org" Content-Type: multipart/alternative; boundary=e89a8ffbae3f54890f04e630eedd Subject: [i2rs] Architecture Discussion 4: templates for Policy and QoS mechanisms X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 14:56:02 -0000 --e89a8ffbae3f54890f04e630eedd Content-Type: text/plain; charset=ISO-8859-1 In draft-ietf-i2rs-architecture-00 Sec 5.4.4: " Many network elements have separate policy and QoS mechanisms, including knobs which affect local path computation and queue control capabilities. These capabilities vary widely across implementations, and I2RS cannot model the full range of information collection or manipulation of these attributes. A core set does need to be included in the I2RS data models and in the expected interfaces between the I2RS Agent and the network element, in order to provide basic capabilities and the hooks for future extensibility. [[Editor's note: This requires more discussion in the working group.]]" I would like to start that discussion now. Personally, I have not seen or heard much discussion or any information-models around these templates. What do people think is necessary? How should this part of the architecture draft change? Thanks, Alia (WG-Chair hat off) --e89a8ffbae3f54890f04e630eedd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
In draft-ietf-= i2rs-architecture-00 Sec 5.4.4:

" Many network elements have sep= arate policy and QoS mechanisms,
   including knobs which affec=
t local path computation and queue control
   capabilities.  These capabilities vary widely across implementations,
   and I2RS cannot model the full range of information collection or
   manipulation of these attributes.  A core set does need to be
   included in the I2RS data models and in the expected interfaces
   between the I2RS Agent and the network element, in order to provide
   basic capabilities and the hooks for future extensibility.
   [[Editor's note: This requires more discussion in the working
   group.]]"
=

I would like to start that disc=
ussion now.  

=

Personally, I have not seen or=
 heard much discussion or any information-models
around these templates.  What d=
o people think is necessary?  How should this
part of the architecture draft change?


Thanks,


Alia (WG-Chair hat off)=




--e89a8ffbae3f54890f04e630eedd-- From akatlas@gmail.com Thu Sep 12 08:00:58 2013 Return-Path: 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 57AE311E825E for ; Thu, 12 Sep 2013 08:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 zQ97OhP45Kel for ; Thu, 12 Sep 2013 08:00:21 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id B0E2211E8237 for ; Thu, 12 Sep 2013 08:00:05 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id tp5so22252350ieb.14 for ; Thu, 12 Sep 2013 07:59:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=2xSVYsJZ4YwhUQFRaMKP8zo8bmXQxMzMSkCQtH/yLFQ=; b=B3jjACDQX7IJZPxRGb/luMuACA/gYIa3QEMsObi7/tlgiqFW2WXxVbkdgpo7hgjpPW HboXEK21KK6mBnBsfrXy5iBRJzVG8ZmRc6qDIFsLdwhI1M/wWHyPgwqFHyMiNYV24KkQ IvYLIRF1uKu3isZ72xUy948x6dIQAPlD/2g4MppkyIMJLezaSI1aigLnKcqUGH2SNQ6A 6xDLH7no4VQtCEU2P88yTTVtJncmHLWb+qGtfNXom7zY9dmmFMVuitv7DMVtQoRgkLsL uWVp2scygBhA/aa3KiDFqrxgGufX1awaaefjyMywERjpozgGKUPHAvadet16IhifRfhO ZCxA== MIME-Version: 1.0 X-Received: by 10.50.102.99 with SMTP id fn3mr13364054igb.5.1378997980770; Thu, 12 Sep 2013 07:59:40 -0700 (PDT) Received: by 10.64.13.145 with HTTP; Thu, 12 Sep 2013 07:59:40 -0700 (PDT) Date: Thu, 12 Sep 2013 10:59:40 -0400 Message-ID: From: Alia Atlas To: "i2rs@ietf.org" Content-Type: multipart/alternative; boundary=e89a8ffbae3fca371a04e630fc25 Subject: [i2rs] Architecture Discussion 5: Client Redundancy X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 15:00:58 -0000 --e89a8ffbae3fca371a04e630fc25 Content-Type: text/plain; charset=ISO-8859-1 In draft-ietf-i2rs-architecture-00 Sec 6.4.1: "I2RS must support client redundancy. At the simplest, this can be handled by having a primary and a backup network application that both use the same client identity and can successfully authenticate as such. Since I2RS does not require a continuous transport connection and supports multiple transport sessions, this can provide some basic redundancy. However, it does not address concerns for troubleshooting and accountability about knowing which network application is actually active. At a minimum, basic transport information about each connection and time can be logged with the identity. Further discussion is necessary to determine whether additional client identification information is necessary.[[Editor's note: This requires more discussion in the working group.]]" I would like to start this discussion. During and after the Berlin IETF, there was significant discussion on the list. I tried to capture the ideas that were expressed then. Is what is in the draft now sufficient? How should it be improved upon? Thanks, Alia (WG-Chair hat off) --e89a8ffbae3fca371a04e630fc25 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
In draft-ietf-= i2rs-architecture-00 Sec 6.4.1:

"I2RS must support client redundan= cy. At the simplest, this can be
   handled by having a primary=
 and a backup network application that
   both use the same client identity and can successfully authenticate
   as such.  Since I2RS does not require a continuous transport
   connection and supports multiple transport sessions, this can provide
   some basic redundancy.  However, it does not address concerns for

   troublesh=
ooting and accountability about knowing which network
   application is actually active.  At a minimum, basic transport
   information about each connection and time can be logged with the
   identity.  Further discussion is necessary to determine whether
   additional client identification information is necessary.[[Editor's
   note: This requires more discussion in the working group.]]"=


I would like to start this disc=
ussion.  During and after the Berlin IETF, there
was significant discussion on the list.  I t=
ried to capture the ideas that were
expressed then.  Is what is in=
 the draft now sufficient?  How should it be improved
upon?

Thanks,
Alia (WG-Chair hat off)
--e89a8ffbae3fca371a04e630fc25-- From jclarke@cisco.com Thu Sep 12 08:03:38 2013 Return-Path: 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 318CC11E8263 for ; Thu, 12 Sep 2013 08:03:38 -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 s6u-45AY-nTN for ; Thu, 12 Sep 2013 08:03:19 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB3311E8251 for ; Thu, 12 Sep 2013 08:02:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1823; q=dns/txt; s=iport; t=1378998149; x=1380207749; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=xFsV01gPFbLEHvf5pcWLRSCONLdV1ElqdI7eRAi/pZ4=; b=MwNeKoo5NxbZw7qt0icyy8j/92IF4eyKxL0n9ZajAB8pSR8cTbWU04O3 bNBleit+0Sw013YFZ5cJP3yaPzGpwFy7edJuYzFko9eCAMGCDd7cvcPft HZNgYdfO2fBcLiQBN2CyULVdAkg594H3dlfAflLGnNhgNdrsyKNCD43Lq w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFALzWMVKtJV2c/2dsb2JhbABYA4MHOME0gRwWdIIlAQEBAwEBAQFrCgEOAgsOBAYJFg8JAwIBAgEJDCIOBg0BBQIBAYd4Bgy8EgQEjh6BORAHEYQMA5d5kXODPiCBNQ X-IronPort-AV: E=Sophos;i="4.90,891,1371081600"; d="scan'208";a="258887312" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 12 Sep 2013 15:02:19 +0000 Received: from dhcp-10-150-54-134.cisco.com (dhcp-10-150-54-134.cisco.com [10.150.54.134]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r8CF2IIQ002289; Thu, 12 Sep 2013 15:02:19 GMT Message-ID: <5231D77A.9050807@cisco.com> Date: Thu, 12 Sep 2013 11:02:18 -0400 From: Joe Marcus Clarke 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: Alia Atlas References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "i2rs@ietf.org" 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 15:03:38 -0000 On 9/12/13 10:47 AM, Alia Atlas wrote: > In draft-ietf-i2rs-architecture-00 Sec 5.2, it says: > > "The I2RS Agent will not attempt to retain or reapply state across > > routing element reboot. Determination of whether state still applies > depends heavily on the causes of reboots, and reapplication is at > least as likely to cause problems as it is to provide for correct > operation. [[Editor's note: This topics needs more discussion in the > working group.]]" > > > I would like to start that discussion and rapidly conclude it with the needed > > changes (removal of the Editor's note or otherwise). > > > My personal impression is that simplifying to just ephemeral state was > > viewed as a good idea. What do others think? Does anyone strongly > > disagree? I agree that ephemeral state is a good idea. But I think we need to be a bit clearer on where the ephemerality lies. That is, if the Agent goes away independent of the routing system, does the state go away? Does the RS retain the state until reboot of the network element? IMHO, the ephemeral state should be maintained with the Agent, and if it goes away (if it can go away independent from the RS), then the state should go away with it. Joe > > > Thanks, > > Alia (WG-chair hat off) > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > -- 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 ---------------------------------------------------------------------------- From akatlas@gmail.com Thu Sep 12 08:03:43 2013 Return-Path: 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 55B4F11E8289 for ; Thu, 12 Sep 2013 08:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 cGpSi-JxuJfP for ; Thu, 12 Sep 2013 08:03:42 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id AC73E11E8272 for ; Thu, 12 Sep 2013 08:02:44 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id e14so7962879iej.38 for ; Thu, 12 Sep 2013 08:02:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=+ZSeuN//pMwxbCYcqVdB2unBVyv1BvChWqHexwoR9GE=; b=BYdpiNTkaM4L+/AigSQ3jXIaE6fBQmTe+VLFDF1C9ZUt5Y+dIJPmVECm7rb52vbUzL 3U2iPKfEWq5iUuq/qyjrxRAnc6b4Sq6iG3nAmx3kBGwAXLjffv//udVOKuhUyF/4zSuA 7yP8M8AebKLMDTz9fikdluG1Rlyd3GiyiYw0mkK+if1XVIgWWN+B+FtxTeUFmVkQyoF9 m+1iWNVOXIgG7fePbRAAhI0JXz64UQ/aUnNE2b+SZy3sR6lasMnmVKI0dRrMlVa8KYm7 hYlTpVCjMTOvZEI6s1ww7WjzUUgqAcdKVQn9Vml1Ff7YGNjzriwab/bcb0xr1w+usJO2 5Ifw== MIME-Version: 1.0 X-Received: by 10.50.119.70 with SMTP id ks6mr1909586igb.22.1378998162176; Thu, 12 Sep 2013 08:02:42 -0700 (PDT) Received: by 10.64.13.145 with HTTP; Thu, 12 Sep 2013 08:02:42 -0700 (PDT) Date: Thu, 12 Sep 2013 11:02:42 -0400 Message-ID: From: Alia Atlas To: "i2rs@ietf.org" Content-Type: multipart/alternative; boundary=089e0111d9b89a4ff504e63107ff Subject: [i2rs] General Architecture Discussion X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 15:03:43 -0000 --089e0111d9b89a4ff504e63107ff Content-Type: text/plain; charset=ISO-8859-1 (WG-Chair hat off) I'd like to get more feedback on draft-ietf-i2rs-architecture-00 - down to the editorial - so that we can revise it and, ideally, have it ready to progress very soon. Towards that end, I've sent email to start up different discussions based upon the Editors' Notes in the draft. I'd also welcome discussion and comments on other topics in the architecture on this thread. Thanks, Alia --089e0111d9b89a4ff504e63107ff Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
(WG-Chair hat off)

I'd like to get = more feedback on draft-ietf-i2rs-architecture-00 - down to the editorial - = so that we can revise it and, ideally, have it ready to progress very soon.=

Towards that end, I've sent email to start up diffe= rent discussions based upon the Editors' Notes in the draft. =A0 I'= d also welcome discussion and comments on other topics in the architecture = on this thread.

Thanks,
Alia
--089e0111d9b89a4ff504e63107ff-- From akatlas@gmail.com Thu Sep 12 08:11:08 2013 Return-Path: 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 6738011E8238 for ; Thu, 12 Sep 2013 08:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 oyi+8jUcldHU for ; Thu, 12 Sep 2013 08:11:07 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id D447611E8235 for ; Thu, 12 Sep 2013 08:11:06 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id e14so8298316iej.10 for ; Thu, 12 Sep 2013 08:11:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bnA7wqKIXRp49hEjuRJhPyqjFInIhUAsYw0cLBkaQxo=; b=zg/Zgh8mCuAxZI1qLml8gYVF98j2w/oI973OfnL9LKeJ2T/+/LOKOsub/+PHc2q0tZ LdvusiVBuYJ6HzcRtxJrAc7XeSjY2ZsIpDysk7IBRQv9GgglCciCBbrvyz1JXX4H9GXK RI1Ptwu3kBnopoP/x+4IwZZZx6M7JppvQsKrDXTz/OevHy2aUHURKiu7mEJQToiDfy5D ejqpxWJf8eVW90HQiMFfetrP7n7dtjHN81HvuYl2T3RiO+K+e/owPE2D5ItPatBJ/pFY T9yBvY1HTDb8TQXSS5drx5jF+/vXwv9dURaeAVCu0d2DaX6cHwexNqvb/nw00Oi3YanP QwfA== MIME-Version: 1.0 X-Received: by 10.50.22.105 with SMTP id c9mr13764833igf.36.1378998660947; Thu, 12 Sep 2013 08:11:00 -0700 (PDT) Received: by 10.64.13.145 with HTTP; Thu, 12 Sep 2013 08:11:00 -0700 (PDT) In-Reply-To: <5231D77A.9050807@cisco.com> References: <5231D77A.9050807@cisco.com> Date: Thu, 12 Sep 2013 11:11:00 -0400 Message-ID: From: Alia Atlas To: Joe Marcus Clarke Content-Type: multipart/alternative; boundary=047d7b10cd8354e94304e63125a1 Cc: "i2rs@ietf.org" 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 15:11:08 -0000 --047d7b10cd8354e94304e63125a1 Content-Type: text/plain; charset=ISO-8859-1 Hi Joe, On Thu, Sep 12, 2013 at 11:02 AM, Joe Marcus Clarke wrote: > On 9/12/13 10:47 AM, Alia Atlas wrote: > > In draft-ietf-i2rs-architecture-00 Sec 5.2, it says: > > > > "The I2RS Agent will not attempt to retain or reapply state across > > > > routing element reboot. Determination of whether state still applies > > depends heavily on the causes of reboots, and reapplication is at > > least as likely to cause problems as it is to provide for correct > > operation. [[Editor's note: This topics needs more discussion in the > > working group.]]" > > > > > > I would like to start that discussion and rapidly conclude it with the > needed > > > > changes (removal of the Editor's note or otherwise). > > > > > > My personal impression is that simplifying to just ephemeral state was > > > > viewed as a good idea. What do others think? Does anyone strongly > > > > disagree? > > I agree that ephemeral state is a good idea. But I think we need to be > a bit clearer on where the ephemerality lies. That is, if the Agent > goes away independent of the routing system, does the state go away? > Does the RS retain the state until reboot of the network element? > > IMHO, the ephemeral state should be maintained with the Agent, and if it > goes away (if it can go away independent from the RS), then the state > should go away with it. > [Alia] This is a really good point to clarify. If the I2RS Agent goes away, cleaning up ephemeral state that it had programmed seems like it would require an additional gate-keeper to keep track of that state and do the cleaning up. That seems painful to me in terms of complexity and storage. I am assuming an unplanned Agent departure rather than an orderly disabling of the Agent. If the Agent simply fails, then IMHO, the ephemeral state should remain - but it is no longer owned by a particular client and could be overwritten... If an Agent is disabled, then it can notify each client that that client's state has been preempted and do an orderly (?) removal of the state. The gotcha with the orderly removal of the state would be understanding the dependencies of the state so that it can be cleanly removed. [Alia] So, I think we're picturing almost opposite things for this behavior - possibly based upon the particular case. What do you think? Alia > > > > > Thanks, > > > > Alia (WG-chair hat off) > > > > > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > > > > -- > 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 > > > ---------------------------------------------------------------------------- > --047d7b10cd8354e94304e63125a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Joe,

On Thu, Sep 12, 2013 at 11:02 AM, Joe Marcus Clarke <jclarke@cisco.= com> wrote:
On 9= /12/13 10:47 AM, Alia Atlas wrote:
> In draft-ietf-i2rs-architecture-00 Sec 5.2, it says:
>
> "The I2RS Agent will not attempt to retain or reapply state acros= s
>
> =A0 =A0routing element reboot. =A0Determination of whether state still= applies
> =A0 =A0depends heavily on the causes of reboots, and reapplication is = at
> =A0 =A0least as likely to cause problems as it is to provide for corre= ct
> =A0 =A0operation. =A0[[Editor's note: This topics needs more discu= ssion in the
> =A0 =A0working group.]]"
>
>
> I would like to start that discussion and rapidly conclude it with the= needed
>
> changes (removal of the Editor's note or otherwise).
>
>
> My personal impression is that simplifying to just ephemeral state was=
>
> viewed as a good idea. =A0What do others think? =A0Does anyone strongl= y
>
> disagree?

I agree that ephemeral state is a good idea. =A0But I think we = need to be
a bit clearer on where the ephemerality lies. =A0That is, if the Agent
goes away independent of the routing system, does the state go away?
Does the RS retain the state until reboot of the network element?

IMHO, the ephemeral state should be maintained with the Agent, and if it goes away (if it can go away independent from the RS), then the state
should go away with it.

[Alia] This is = a really good point to clarify. =A0If the I2RS Agent goes away, cleaning up=
ephemeral state that it had programmed seems like it would requi= re an additional gate-keeper
to keep track of that state and do the cleaning up. =A0 That seems pai= nful to me in terms of
complexity and storage. =A0I am assuming a= n unplanned Agent departure rather than an orderly
disabling of t= he Agent. =A0 =A0 If the Agent simply fails, then IMHO, the ephemeral state= should
remain - but it is no longer owned by a particular client and could be= overwritten... =A0If an Agent is
disabled, then it can notify ea= ch client that that client's state has been preempted and do an
orderly (?) removal of the state. =A0The gotcha with the orderly remov= al of the state would be understanding
the dependencies of the st= ate so that it can be cleanly removed.

[Alia] So, = I think we're picturing almost opposite things for this behavior - poss= ibly based upon the=A0
particular case. =A0 What do you think?

Alia<= /div>

>
>
> Thanks,
>
> Alia (WG-chair hat off)
>
>
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>


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

---------------------------------------------------------------------------= -

--047d7b10cd8354e94304e63125a1-- From jmh@joelhalpern.com Thu Sep 12 08:11:42 2013 Return-Path: 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 80F1E11E8242 for ; Thu, 12 Sep 2013 08:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.14 X-Spam-Level: X-Spam-Status: No, score=-102.14 tagged_above=-999 required=5 tests=[AWL=0.459, BAYES_00=-2.599, 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 qBG8UstZnrTK for ; Thu, 12 Sep 2013 08:11:37 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 80E8E11E8237 for ; Thu, 12 Sep 2013 08:11:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 38B7D220526; Thu, 12 Sep 2013 08:11:34 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (c213-89-137-101.bredband.comhem.se [213.89.137.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id A22901C013E; Thu, 12 Sep 2013 08:11:32 -0700 (PDT) Message-ID: <5231D9A1.5060709@joelhalpern.com> Date: Thu, 12 Sep 2013 11:11:29 -0400 From: "Joel M. Halpern" 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: Joe Marcus Clarke References: <5231D77A.9050807@cisco.com> In-Reply-To: <5231D77A.9050807@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "i2rs@ietf.org" , Alia Atlas 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 15:11:43 -0000 My perspective on ephemeral was that it was ephemeral from the perspective of the device with the I2RS agent. If that device reboots, the state is gone. No persistent storage. I do not want the I2RS agent to have to maintain TCP connections with all I2RS clients that have state in the device. Such a connection is overhead both in terms of state and packets, for very little gain. In general, if the client created the state, it should remain until the client explicitly clears it. Presumably, as part of operational behaviors, the clients take care to keep track of what they have done in a robust fashion. There are ways to create cleanup mechanisms, but I would not recommend that as a common practice. Yours, Joel On 9/12/13 11:02 AM, Joe Marcus Clarke wrote: > On 9/12/13 10:47 AM, Alia Atlas wrote: >> In draft-ietf-i2rs-architecture-00 Sec 5.2, it says: >> >> "The I2RS Agent will not attempt to retain or reapply state across >> >> routing element reboot. Determination of whether state still applies >> depends heavily on the causes of reboots, and reapplication is at >> least as likely to cause problems as it is to provide for correct >> operation. [[Editor's note: This topics needs more discussion in the >> working group.]]" >> >> >> I would like to start that discussion and rapidly conclude it with the needed >> >> changes (removal of the Editor's note or otherwise). >> >> >> My personal impression is that simplifying to just ephemeral state was >> >> viewed as a good idea. What do others think? Does anyone strongly >> >> disagree? > > I agree that ephemeral state is a good idea. But I think we need to be > a bit clearer on where the ephemerality lies. That is, if the Agent > goes away independent of the routing system, does the state go away? > Does the RS retain the state until reboot of the network element? > > IMHO, the ephemeral state should be maintained with the Agent, and if it > goes away (if it can go away independent from the RS), then the state > should go away with it. > > Joe > >> >> >> Thanks, >> >> Alia (WG-chair hat off) >> >> >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> > > From jclarke@cisco.com Thu Sep 12 08:18:42 2013 Return-Path: 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 B725821E80C3 for ; Thu, 12 Sep 2013 08:18:40 -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 GVCZb717N+7g for ; Thu, 12 Sep 2013 08:18:20 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id BC46621E809F for ; Thu, 12 Sep 2013 08:18:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3485; q=dns/txt; s=iport; t=1378999099; x=1380208699; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=txSb2h3D2Sk9kZsSZjk5tqofNVHUdGONm5xqxBHqH2c=; b=gNldvduu4EhYwnyGZJUm6dptaWujwrHL/7AN+w/6M6ahNo4wO6AWBVc4 CVRtgbXkOJ3KxKrlbsqyDZCnjcaJi31Ay/RtQYpRAzh0qCSB428aXfN7A uwzCn0feOCoNNTp3sCOJ/yUuEqf9eLAaS0VAPOvoTY1niZWcDQ9Bq3KPY s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAEfaMVKtJXG//2dsb2JhbABYA4MHOME0gRwWdIIlAQEBAwEBAQFpAggCAQ4CCxIGCRYPCQMCAQIBCQwiDgYNAQUCAQGHeAYMvB0EBI4eFoEjEAcRhAwDl3mRc4M+IIEtCBc X-IronPort-AV: E=Sophos;i="4.90,891,1371081600"; d="scan'208";a="258895872" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 12 Sep 2013 15:18:17 +0000 Received: from dhcp-10-150-54-134.cisco.com (dhcp-10-150-54-134.cisco.com [10.150.54.134]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r8CFIGd0017215; Thu, 12 Sep 2013 15:18:16 GMT Message-ID: <5231DB38.9070306@cisco.com> Date: Thu, 12 Sep 2013 11:18:16 -0400 From: Joe Marcus Clarke 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: "Joel M. Halpern" References: <5231D77A.9050807@cisco.com> <5231D9A1.5060709@joelhalpern.com> In-Reply-To: <5231D9A1.5060709@joelhalpern.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "i2rs@ietf.org" , Alia Atlas 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 15:18:42 -0000 On 9/12/13 11:11 AM, Joel M. Halpern wrote: > My perspective on ephemeral was that it was ephemeral from the > perspective of the device with the I2RS agent. If that device reboots, > the state is gone. No persistent storage. > > I do not want the I2RS agent to have to maintain TCP connections with > all I2RS clients that have state in the device. Such a connection is > overhead both in terms of state and packets, for very little gain. In > general, if the client created the state, it should remain until the > client explicitly clears it. Presumably, as part of operational > behaviors, the clients take care to keep track of what they have done in > a robust fashion. > There are ways to create cleanup mechanisms, but I would not recommend > that as a common practice. I was thinking the same thing from the Client perspective. That is, the state is maintained by the Agent. My comment was what happens if the Agent goes away, but the RS remains (i.e., a cold start of the Agent independent from the underlying network element RS)? The reason I think the RS state needs to go away with the Agent is that if the Agent reboots, and it comes back, how could Clients operate on their previous state? The Agent would have no knowledge of that state since the Agent maintains to persistent storage. Therefore, you could get state in the RS that is impossible to remove without a reboot of the underlying NE. That is bad. Joe > > Yours, > Joel > > On 9/12/13 11:02 AM, Joe Marcus Clarke wrote: >> On 9/12/13 10:47 AM, Alia Atlas wrote: >>> In draft-ietf-i2rs-architecture-00 Sec 5.2, it says: >>> >>> "The I2RS Agent will not attempt to retain or reapply state across >>> >>> routing element reboot. Determination of whether state still >>> applies >>> depends heavily on the causes of reboots, and reapplication is at >>> least as likely to cause problems as it is to provide for correct >>> operation. [[Editor's note: This topics needs more discussion in >>> the >>> working group.]]" >>> >>> >>> I would like to start that discussion and rapidly conclude it with >>> the needed >>> >>> changes (removal of the Editor's note or otherwise). >>> >>> >>> My personal impression is that simplifying to just ephemeral state was >>> >>> viewed as a good idea. What do others think? Does anyone strongly >>> >>> disagree? >> >> I agree that ephemeral state is a good idea. But I think we need to be >> a bit clearer on where the ephemerality lies. That is, if the Agent >> goes away independent of the routing system, does the state go away? >> Does the RS retain the state until reboot of the network element? >> >> IMHO, the ephemeral state should be maintained with the Agent, and if it >> goes away (if it can go away independent from the RS), then the state >> should go away with it. >> >> Joe >> >>> >>> >>> Thanks, >>> >>> Alia (WG-chair hat off) >>> >>> >>> >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>> >> >> -- 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 ---------------------------------------------------------------------------- From jclarke@cisco.com Thu Sep 12 08:22:59 2013 Return-Path: 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 7581111E824F for ; Thu, 12 Sep 2013 08:22:48 -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 0SNfE3yvoS4v for ; Thu, 12 Sep 2013 08:22:38 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 24DB211E81BB for ; Thu, 12 Sep 2013 08:22:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4359; q=dns/txt; s=iport; t=1378999337; x=1380208937; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=EI2ZqGlDSKpmxNqPxhQsqaS+MfQIyPjmJ6HaYK91v/Y=; b=KghptGBsUE73Tf2IAbJOUh/ZIPWAmAsbyZxOg4ePYtaghhgr8opTFbXH u6j3XarP9jOeXrybLA3h7Sg1qwXAuPWMHxJ/GABZqdp0V4fgrV7fS5cXS DXo2PpWbpp078fb5i1YjI3IrWYXXOyQ0HeRWGxbBpqIo+nKk5MrJALA60 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFADbbMVKtJXG9/2dsb2JhbABYA4MHOME0gRwWdIIlAQEBAwEBAQFrCgEOAgsOBAYJFggHCQMCAQIBCQwfAw4GDQEFAgEBh3gGDLweBASOHhaBIxAHEYQMA5d5kXODPiCBLQgX X-IronPort-AV: E=Sophos;i="4.90,891,1371081600"; d="scan'208";a="255901377" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 12 Sep 2013 15:22:16 +0000 Received: from dhcp-10-150-54-134.cisco.com (dhcp-10-150-54-134.cisco.com [10.150.54.134]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r8CFMGP5003822; Thu, 12 Sep 2013 15:22:16 GMT Message-ID: <5231DC28.9060600@cisco.com> Date: Thu, 12 Sep 2013 11:22:16 -0400 From: Joe Marcus Clarke 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: Alia Atlas References: <5231D77A.9050807@cisco.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "i2rs@ietf.org" 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 15:22:59 -0000 On 9/12/13 11:11 AM, Alia Atlas wrote: > Hi Joe, > > On Thu, Sep 12, 2013 at 11:02 AM, Joe Marcus Clarke > wrote: > > On 9/12/13 10:47 AM, Alia Atlas wrote: > > In draft-ietf-i2rs-architecture-00 Sec 5.2, it says: > > > > "The I2RS Agent will not attempt to retain or reapply state across > > > > routing element reboot. Determination of whether state still > applies > > depends heavily on the causes of reboots, and reapplication is at > > least as likely to cause problems as it is to provide for correct > > operation. [[Editor's note: This topics needs more discussion > in the > > working group.]]" > > > > > > I would like to start that discussion and rapidly conclude it with > the needed > > > > changes (removal of the Editor's note or otherwise). > > > > > > My personal impression is that simplifying to just ephemeral state was > > > > viewed as a good idea. What do others think? Does anyone strongly > > > > disagree? > > I agree that ephemeral state is a good idea. But I think we need to be > a bit clearer on where the ephemerality lies. That is, if the Agent > goes away independent of the routing system, does the state go away? > Does the RS retain the state until reboot of the network element? > > IMHO, the ephemeral state should be maintained with the Agent, and if it > goes away (if it can go away independent from the RS), then the state > should go away with it. > > > [Alia] This is a really good point to clarify. If the I2RS Agent goes > away, cleaning up > ephemeral state that it had programmed seems like it would require an > additional gate-keeper > to keep track of that state and do the cleaning up. That seems painful > to me in terms of > complexity and storage. I am assuming an unplanned Agent departure > rather than an orderly > disabling of the Agent. If the Agent simply fails, then IMHO, the > ephemeral state should > remain - but it is no longer owned by a particular client and could be > overwritten... If an Agent is > disabled, then it can notify each client that that client's state has > been preempted and do an > orderly (?) removal of the state. The gotcha with the orderly removal > of the state would be understanding > the dependencies of the state so that it can be cleanly removed. > > [Alia] So, I think we're picturing almost opposite things for this > behavior - possibly based upon the > particular case. What do you think? See my response to Joel. I think we have to deal with this complexity because if we don't and the Agent goes away, how could Clients then come in to remove their state? That is, the RS retains the Agent-programmed state, but when the Agent reboots, it has no state. At the worst, we have RS state that a Client cannot manipulate. At best, we would open RS state to Clients that did not make the original change. I think we have to say, to an implementor, if the Agent goes away, the RS must handle cleaning up all state installed by that Agent. Joe > > Alia > > > > > > > Thanks, > > > > Alia (WG-chair hat off) > > > > > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > > > > -- > 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 > > ---------------------------------------------------------------------------- > > -- 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 ---------------------------------------------------------------------------- From jmh@joelhalpern.com Thu Sep 12 08:23:05 2013 Return-Path: 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 0BCD721E8119 for ; Thu, 12 Sep 2013 08:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.232 X-Spam-Level: X-Spam-Status: No, score=-102.232 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, 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 b8FVj60CO7nO for ; Thu, 12 Sep 2013 08:22:59 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 40A3D21F8484 for ; Thu, 12 Sep 2013 08:22:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 22EF022056A; Thu, 12 Sep 2013 08:22:27 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (c213-89-137-101.bredband.comhem.se [213.89.137.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id AA97A220566; Thu, 12 Sep 2013 08:22:06 -0700 (PDT) Message-ID: <5231DC1B.9020802@joelhalpern.com> Date: Thu, 12 Sep 2013 11:22:03 -0400 From: "Joel M. Halpern" 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: Joe Marcus Clarke References: <5231D77A.9050807@cisco.com> <5231D9A1.5060709@joelhalpern.com> <5231DB38.9070306@cisco.com> In-Reply-To: <5231DB38.9070306@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "i2rs@ietf.org" , Alia Atlas 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 15:23:05 -0000 Okay. Then I misunderstood your note and I agree with you. If the I2RS Agent in a device goes down, all the state it created in the device needs to go away. Thank you, Joel On 9/12/13 11:18 AM, Joe Marcus Clarke wrote: > On 9/12/13 11:11 AM, Joel M. Halpern wrote: >> My perspective on ephemeral was that it was ephemeral from the >> perspective of the device with the I2RS agent. If that device reboots, >> the state is gone. No persistent storage. >> >> I do not want the I2RS agent to have to maintain TCP connections with >> all I2RS clients that have state in the device. Such a connection is >> overhead both in terms of state and packets, for very little gain. In >> general, if the client created the state, it should remain until the >> client explicitly clears it. Presumably, as part of operational >> behaviors, the clients take care to keep track of what they have done in >> a robust fashion. >> There are ways to create cleanup mechanisms, but I would not recommend >> that as a common practice. > > I was thinking the same thing from the Client perspective. That is, the > state is maintained by the Agent. My comment was what happens if the > Agent goes away, but the RS remains (i.e., a cold start of the Agent > independent from the underlying network element RS)? The reason > > I think the RS state needs to go away with the Agent is that if the > Agent reboots, and it comes back, how could Clients operate on their > previous state? The Agent would have no knowledge of that state since > the Agent maintains to persistent storage. Therefore, you could get > state in the RS that is impossible to remove without a reboot of the > underlying NE. That is bad. > > Joe > >> >> Yours, >> Joel >> >> On 9/12/13 11:02 AM, Joe Marcus Clarke wrote: >>> On 9/12/13 10:47 AM, Alia Atlas wrote: >>>> In draft-ietf-i2rs-architecture-00 Sec 5.2, it says: >>>> >>>> "The I2RS Agent will not attempt to retain or reapply state across >>>> >>>> routing element reboot. Determination of whether state still >>>> applies >>>> depends heavily on the causes of reboots, and reapplication is at >>>> least as likely to cause problems as it is to provide for correct >>>> operation. [[Editor's note: This topics needs more discussion in >>>> the >>>> working group.]]" >>>> >>>> >>>> I would like to start that discussion and rapidly conclude it with >>>> the needed >>>> >>>> changes (removal of the Editor's note or otherwise). >>>> >>>> >>>> My personal impression is that simplifying to just ephemeral state was >>>> >>>> viewed as a good idea. What do others think? Does anyone strongly >>>> >>>> disagree? >>> >>> I agree that ephemeral state is a good idea. But I think we need to be >>> a bit clearer on where the ephemerality lies. That is, if the Agent >>> goes away independent of the routing system, does the state go away? >>> Does the RS retain the state until reboot of the network element? >>> >>> IMHO, the ephemeral state should be maintained with the Agent, and if it >>> goes away (if it can go away independent from the RS), then the state >>> should go away with it. >>> >>> Joe >>> >>>> >>>> >>>> Thanks, >>>> >>>> Alia (WG-chair hat off) >>>> >>>> >>>> >>>> _______________________________________________ >>>> i2rs mailing list >>>> i2rs@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i2rs >>>> >>> >>> > > From akatlas@gmail.com Thu Sep 12 08:31:57 2013 Return-Path: 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 12ABD21E80D1 for ; Thu, 12 Sep 2013 08:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 9idz1s0WSzAp for ; Thu, 12 Sep 2013 08:31:42 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id C3C4021E80D8 for ; Thu, 12 Sep 2013 08:31:04 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id aq17so22797223iec.27 for ; Thu, 12 Sep 2013 08:31:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IQuZcsFg+bTTIu0rRI3pyQbF6QOmNhFl3fnZc7PC4KY=; b=gkZNHTN7dnLe1fgTh7zbql60fB+eW3iTygnwJqqP5OfWLNThUgHEltU6apWm/Cs0iA uzL2XWPj7+OqaLLwJiR4r66mW12vBELgsHj2zjIa3wbbbZFuILAFbTgL9RY4XcIW0RbK uTLGnOMPNLVipAjTNo7H2Hkv/EXIjCb3H+Pv17wM1EFPykOGwW1MS/WqZwjrnDq7H1X9 psRLD4Q4Ov3E0ILplZEaZVvIiZpjOLJv/6gaX2KeW+amFuX001srSeYiT0Erf+gOqjvN tGCd4Qasfxn8YXfmL8iL+ZBhAEfzuE1asV8K9gIdtXkl5stS2aMTSle6SsWJ/6YZN7xG ZClA== MIME-Version: 1.0 X-Received: by 10.50.30.42 with SMTP id p10mr1884295igh.5.1378999864282; Thu, 12 Sep 2013 08:31:04 -0700 (PDT) Received: by 10.64.13.145 with HTTP; Thu, 12 Sep 2013 08:31:04 -0700 (PDT) In-Reply-To: <5231DC28.9060600@cisco.com> References: <5231D77A.9050807@cisco.com> <5231DC28.9060600@cisco.com> Date: Thu, 12 Sep 2013 11:31:04 -0400 Message-ID: From: Alia Atlas To: Joe Marcus Clarke Content-Type: multipart/alternative; boundary=047d7bdc9db20e555c04e6316dd1 Cc: "i2rs@ietf.org" 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 15:32:02 -0000 --047d7bdc9db20e555c04e6316dd1 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 12, 2013 at 11:22 AM, Joe Marcus Clarke wrote: > On 9/12/13 11:11 AM, Alia Atlas wrote: > > Hi Joe, > > > > On Thu, Sep 12, 2013 at 11:02 AM, Joe Marcus Clarke > > wrote: > > > > On 9/12/13 10:47 AM, Alia Atlas wrote: > > > In draft-ietf-i2rs-architecture-00 Sec 5.2, it says: > > > > > > "The I2RS Agent will not attempt to retain or reapply state across > > > > > > routing element reboot. Determination of whether state still > > applies > > > depends heavily on the causes of reboots, and reapplication is > at > > > least as likely to cause problems as it is to provide for > correct > > > operation. [[Editor's note: This topics needs more discussion > > in the > > > working group.]]" > > > > > > > > > I would like to start that discussion and rapidly conclude it with > > the needed > > > > > > changes (removal of the Editor's note or otherwise). > > > > > > > > > My personal impression is that simplifying to just ephemeral state > was > > > > > > viewed as a good idea. What do others think? Does anyone strongly > > > > > > disagree? > > > > I agree that ephemeral state is a good idea. But I think we need to > be > > a bit clearer on where the ephemerality lies. That is, if the Agent > > goes away independent of the routing system, does the state go away? > > Does the RS retain the state until reboot of the network element? > > > > IMHO, the ephemeral state should be maintained with the Agent, and > if it > > goes away (if it can go away independent from the RS), then the state > > should go away with it. > > > > > > [Alia] This is a really good point to clarify. If the I2RS Agent goes > > away, cleaning up > > ephemeral state that it had programmed seems like it would require an > > additional gate-keeper > > to keep track of that state and do the cleaning up. That seems painful > > to me in terms of > > complexity and storage. I am assuming an unplanned Agent departure > > rather than an orderly > > disabling of the Agent. If the Agent simply fails, then IMHO, the > > ephemeral state should > > remain - but it is no longer owned by a particular client and could be > > overwritten... If an Agent is > > disabled, then it can notify each client that that client's state has > > been preempted and do an > > orderly (?) removal of the state. The gotcha with the orderly removal > > of the state would be understanding > > the dependencies of the state so that it can be cleanly removed. > > > > [Alia] So, I think we're picturing almost opposite things for this > > behavior - possibly based upon the > > particular case. What do you think? > > See my response to Joel. I think we have to deal with this complexity > because if we don't and the Agent goes away, how could Clients then come > in to remove their state? That is, the RS retains the Agent-programmed > state, but when the Agent reboots, it has no state. At the worst, we > have RS state that a Client cannot manipulate. At best, we would open > RS state to Clients that did not make the original change. > [Alia] I don't think that we've included locking for I2RS - so I can't see how we'd have RS that a client cannot manipulate. Whether state is removed(changed back to the default) or left, we will definitely have the ability for a Client to add or change the RS state. > I think we have to say, to an implementor, if the Agent goes away, the > RS must handle cleaning up all state installed by that Agent. > [Alia] I think that it could be either way - that the state remains but can be overwritten or that the RS has to clean up the state. I'm concerned that in the RS cleans up the state case, there is no way for the Client to learn that its state has been removed (assuming a failure on the part of the Agent rather than an orderly removal). I'd prefer to see the state remain for that reason for the Agent-failure case. What do you think? Alia > > Joe > > > > > Alia > > > > > > > > > > > Thanks, > > > > > > Alia (WG-chair hat off) > > > > > > > > > > > > _______________________________________________ > > > i2rs mailing list > > > i2rs@ietf.org > > > https://www.ietf.org/mailman/listinfo/i2rs > > > > > > > > > -- > > 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 > > > > > ---------------------------------------------------------------------------- > > > > > > > -- > 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 > > > ---------------------------------------------------------------------------- > --047d7bdc9db20e555c04e6316dd1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Sep 12, 2013 at 11:22 AM, Joe Marcus Clarke <jcla= rke@cisco.com> wrote:
On 9/12/13 11:11 AM, Alia = Atlas wrote:
> Hi Joe,
>
> On Thu, Sep 12, 2013 at 11:02 AM, Joe Marcus Clarke <jclarke@cisco.com
> <mailto:jclarke@cisco.com>> wrote:
>
> =A0 =A0 On 9/12/13 10:47 AM, Alia Atlas wrote:
> =A0 =A0 > In draft-ietf-i2rs-architecture-00 Sec 5.2, it says:
> =A0 =A0 >
> =A0 =A0 > "The I2RS Agent will not attempt to retain or reappl= y state across
> =A0 =A0 >
> =A0 =A0 > =A0 =A0routing element reboot. =A0Determination of whethe= r state still
> =A0 =A0 applies
> =A0 =A0 > =A0 =A0depends heavily on the causes of reboots, and reap= plication is at
> =A0 =A0 > =A0 =A0least as likely to cause problems as it is to prov= ide for correct
> =A0 =A0 > =A0 =A0operation. =A0[[Editor's note: This topics nee= ds more discussion
> =A0 =A0 in the
> =A0 =A0 > =A0 =A0working group.]]"
> =A0 =A0 >
> =A0 =A0 >
> =A0 =A0 > I would like to start that discussion and rapidly conclud= e it with
> =A0 =A0 the needed
> =A0 =A0 >
> =A0 =A0 > changes (removal of the Editor's note or otherwise).<= br> > =A0 =A0 >
> =A0 =A0 >
> =A0 =A0 > My personal impression is that simplifying to just epheme= ral state was
> =A0 =A0 >
> =A0 =A0 > viewed as a good idea. =A0What do others think? =A0Does a= nyone strongly
> =A0 =A0 >
> =A0 =A0 > disagree?
>
> =A0 =A0 I agree that ephemeral state is a good idea. =A0But I think we= need to be
> =A0 =A0 a bit clearer on where the ephemerality lies. =A0That is, if t= he Agent
> =A0 =A0 goes away independent of the routing system, does the state go= away?
> =A0 =A0 Does the RS retain the state until reboot of the network eleme= nt?
>
> =A0 =A0 IMHO, the ephemeral state should be maintained with the Agent,= and if it
> =A0 =A0 goes away (if it can go away independent from the RS), then th= e state
> =A0 =A0 should go away with it.
>
>
> [Alia] This is a really good point to clarify. =A0If the I2RS Agent go= es
> away, cleaning up
> ephemeral state that it had programmed seems like it would require an<= br> > additional gate-keeper
> to keep track of that state and do the cleaning up. =A0 That seems pai= nful
> to me in terms of
> complexity and storage. =A0I am assuming an unplanned Agent departure<= br> > rather than an orderly
> disabling of the Agent. =A0 =A0 If the Agent simply fails, then IMHO, = the
> ephemeral state should
> remain - but it is no longer owned by a particular client and could be=
> overwritten... =A0If an Agent is
> disabled, then it can notify each client that that client's state = has
> been preempted and do an
> orderly (?) removal of the state. =A0The gotcha with the orderly remov= al
> of the state would be understanding
> the dependencies of the state so that it can be cleanly removed.
>
> [Alia] So, I think we're picturing almost opposite things for this=
> behavior - possibly based upon the
> particular case. =A0 What do you think?

See my response to Joel. =A0I think we have to deal with this c= omplexity
because if we don't and the Agent goes away, how could Clients then com= e
in to remove their state? =A0That is, the RS retains the Agent-programmed state, but when the Agent reboots, it has no state. =A0At the worst, we
have RS state that a Client cannot manipulate. =A0At best, we would open RS state to Clients that did not make the original change.
=

[Alia] I don't think that we've included lockin= g for I2RS - so I can't see how we'd have
RS that a clien= t cannot manipulate. =A0Whether state is removed(changed back to the
default) =A0or left, we will definitely have the ability for a Client = to add or change the RS
state.
=A0
I think we have to say, to an implementor, if the Agent goes away, the
RS must handle cleaning up all state installed by that Agent.

[Alia] I think that it could be either way - that th= e state remains but can be overwritten
or that the RS has to clea= n up the state. =A0I'm concerned that in the RS cleans up the state
case, there is no way for the Client to learn that its state has been = removed (assuming a
failure on the part of the Agent rather than = an orderly removal). =A0I'd prefer to see the state
remain fo= r that reason for the Agent-failure case. =A0What do you think?

Alia
=A0

Joe =A0

>
> Alia
>
> =A0 =A0 >
> =A0 =A0 >
> =A0 =A0 > Thanks,
> =A0 =A0 >
> =A0 =A0 > Alia (WG-chair hat off)
> =A0 =A0 >
> =A0 =A0 >
> =A0 =A0 >
> =A0 =A0 > _______________________________________________
> =A0 =A0 > i2rs mailing list
> =A0 =A0 > i2rs@ietf.org = <mailto:i2rs@ietf.org>
> =A0 =A0 > https://www.ietf.org/mailman/listinfo/i2r= s
> =A0 =A0 >
>
>
> =A0 =A0 --
> =A0 =A0 Joe Marcus Clarke, CCIE #5384, =A0 =A0 =A0 =A0 | =A0 =A0 =A0 = =A0 =A0|
> =A0 =A0 SCJP, SCSA, SCNA, SCSECA, VCP =A0 =A0 =A0 =A0||||| =A0 =A0 =A0= |||||
> =A0 =A0 Distinguished Services Engineer ..:|||||||||::|||||||||:..
> =A0 =A0 Phone: +1 (919) 392-2867 <tel:%2B1%20%28919%29%20392-2867= > =A0 =A0 =A0 =A0 c
> =A0 =A0 i s c o =A0S y s t e m s
> =A0 =A0 Email: jclarke@cisc= o.com <mailto:jclarke@cisco.com= >
>
> =A0 =A0 --------------------------------------------------------------= --------------
>
>


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

---------------------------------------------------------------------------= -

--047d7bdc9db20e555c04e6316dd1-- From jclarke@cisco.com Thu Sep 12 08:45:30 2013 Return-Path: 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 AE6C321E8107 for ; Thu, 12 Sep 2013 08:45:30 -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 CFiDVNro4vtA for ; Thu, 12 Sep 2013 08:45:07 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id D516C11E8273 for ; Thu, 12 Sep 2013 08:44:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1846; q=dns/txt; s=iport; t=1379000677; x=1380210277; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=fl0NYm/JyW2j1OzVFhyJYn8EoFPtfu0kxqzTvK8DcWQ=; b=djkzqT1qN7rED7uoHPUDM5/Qit6iNf3ejNcf16jJyxp62R2QbtJuK0Y5 Eaf7mHsiIClOiIXoOCiFBBlpb1+tRJsViqvpTjgjMRHfqHNqJbd8ykGhd UwAkErOjA9TXdNaq1SynViECKWbSi+r4uE7Qx31jxcQhE0yDzSdtq+DaP w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAB/gMVKtJV2Y/2dsb2JhbABYA4MHwWyBHBZ0giUBAQEDAXgBDgILDgQGCRYPCQMCAQIBCS4OBg0BBQIBAYd4BrwsBI4egTkQBxGEDAOXeZFzgz4ggTU X-IronPort-AV: E=Sophos;i="4.90,891,1371081600"; d="scan'208";a="258928155" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 12 Sep 2013 15:44:15 +0000 Received: from dhcp-10-150-54-134.cisco.com (dhcp-10-150-54-134.cisco.com [10.150.54.134]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r8CFiEZm027425; Thu, 12 Sep 2013 15:44:14 GMT Message-ID: <5231E14E.5020605@cisco.com> Date: Thu, 12 Sep 2013 11:44:14 -0400 From: Joe Marcus Clarke 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: Alia Atlas References: <5231D77A.9050807@cisco.com> <5231DC28.9060600@cisco.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "i2rs@ietf.org" 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 15:45:31 -0000 On 9/12/13 11:31 AM, Alia Atlas wrote: > [Alia] I don't think that we've included locking for I2RS - so I can't > see how we'd have > RS that a client cannot manipulate. Whether state is removed(changed > back to the > default) or left, we will definitely have the ability for a Client to > add or change the RS > state. Fair enough. > > > I think we have to say, to an implementor, if the Agent goes away, the > RS must handle cleaning up all state installed by that Agent. > > > [Alia] I think that it could be either way - that the state remains but > can be overwritten > or that the RS has to clean up the state. I'm concerned that in the RS > cleans up the state > case, there is no way for the Client to learn that its state has been > removed (assuming a > failure on the part of the Agent rather than an orderly removal). I'd > prefer to see the state > remain for that reason for the Agent-failure case. What do you think? I think the risk of an Agent reboot allowing Client B to change Client A's state warrants the RS cleanup. Plus, if the Client is subscribed to a pub-sub bus then it could presumably learn about an Agent cold start via a published message. At that point, the client could re-establish its state to the Agent. If the Client is not part of the bus, it could periodically connect to the Agent and learn that it was rebooted via the protocol...yeah, this sounds a bit like SNMP, but it seems reasonable to me. 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 ---------------------------------------------------------------------------- From akatlas@gmail.com Thu Sep 12 09:29:30 2013 Return-Path: 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 2F38221E810A for ; Thu, 12 Sep 2013 09:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 CE1u8Sl+2isi for ; Thu, 12 Sep 2013 09:29:29 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id E2C2F11E823B for ; Thu, 12 Sep 2013 09:29:03 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id ar20so69564iec.32 for ; Thu, 12 Sep 2013 09:29:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=okFNlUdxgE807sEY30Cy/IY6X/B7WD9J+cTTEeGW5wo=; b=Q26+Hq5YsOwA70610ebHq9h6E6xvFUDE7qh5eS5a0CVQrJPqrgHLLnGcphnKEIv/MZ 3a1MBlOPrTW/skocRVqYD+tfkf5hCnLMbbxeMgtaVv55Zpu0LcqpBSzCeMb2I6zU203d /IhO1bHrHAs2xmZ/ttjFg/tQID9IQkqsP5Up2YrqBRCufbaxhnQqH0CsyihyufFb9szr 4NE26W5/j7Ee/pQL49nUIalCPl0QyFbRZcl/+U6u5Hnc0DFF8Vff+mi9Y1mSp4/ePt6D iFi4wf+qqreQeVjzKQXr6BeJtgeFLFDcq0s93xe19XpzFH22ALfdGeWivyTkiHghTEay uGyw== MIME-Version: 1.0 X-Received: by 10.50.128.137 with SMTP id no9mr2039122igb.36.1379003343471; Thu, 12 Sep 2013 09:29:03 -0700 (PDT) Received: by 10.64.13.145 with HTTP; Thu, 12 Sep 2013 09:29:03 -0700 (PDT) In-Reply-To: <5231E14E.5020605@cisco.com> References: <5231D77A.9050807@cisco.com> <5231DC28.9060600@cisco.com> <5231E14E.5020605@cisco.com> Date: Thu, 12 Sep 2013 12:29:03 -0400 Message-ID: From: Alia Atlas To: Joe Marcus Clarke Content-Type: multipart/alternative; boundary=047d7b10cf0d6ea15704e6323c09 Cc: "i2rs@ietf.org" 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 16:29:30 -0000 --047d7b10cf0d6ea15704e6323c09 Content-Type: text/plain; charset=ISO-8859-1 Hi Joe, More in-line (good to have the conversation) On Thu, Sep 12, 2013 at 11:44 AM, Joe Marcus Clarke wrote: > On 9/12/13 11:31 AM, Alia Atlas wrote: > > [Alia] I don't think that we've included locking for I2RS - so I can't > > see how we'd have > > RS that a client cannot manipulate. Whether state is removed(changed > > back to the > > default) or left, we will definitely have the ability for a Client to > > add or change the RS > > state. > > Fair enough. > > > > > > > I think we have to say, to an implementor, if the Agent goes away, > the > > RS must handle cleaning up all state installed by that Agent. > > > > > > [Alia] I think that it could be either way - that the state remains but > > can be overwritten > > or that the RS has to clean up the state. I'm concerned that in the RS > > cleans up the state > > case, there is no way for the Client to learn that its state has been > > removed (assuming a > > failure on the part of the Agent rather than an orderly removal). I'd > > prefer to see the state > > remain for that reason for the Agent-failure case. What do you think? > > I think the risk of an Agent reboot allowing Client B to change Client > A's state warrants the RS cleanup. > [Alia] The risk that client B comes and changes the state after an Agent reboot justifies the RS cleanup of that state before?? Remember that Client A and B aren't supposed to be overwriting each other's data. We've defined that as an error case and that policy between the clients should prevent it. > Plus, if the Client is subscribed to a pub-sub bus then it could > presumably learn about an Agent cold start via a published message. At > that point, the client could re-establish its state to the Agent. > [Alia] Hmm, I know there was a draft discussed about pub-sub methods in general - but I don't think that we've really nailed down how pub-sub would work. Absent anything, I'd assume that the I2RS agent is whom the client registers with to get its notifications. Now, if we want to have a different system being a bus (with the scale implications there), that might be different - but I don't think we've really talked about that. So, my assumption is that the Agent provides the notifications to Clients that have registered - and when the Agent reboots, there are no Clients registered to get the notifications. If you have a different model (or different thoughts on what to do for the pub-sub), want to start that discussion (perhaps in a different thread)? > If the Client is not part of the bus, it could periodically connect to > the Agent and learn that it was rebooted via the protocol...yeah, this > sounds a bit like SNMP, but it seems reasonable to me. > [Alia] It doesn't sound reasonable to me... at least not to avoid what should be an error condition. Can we discuss more? Do you have additional justification for the significant added complexity. Regards, Alia > > 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 > > > ---------------------------------------------------------------------------- > --047d7b10cf0d6ea15704e6323c09 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Joe,

More in-line (go= od to have the conversation)

On Thu, Sep = 12, 2013 at 11:44 AM, Joe Marcus Clarke <jclarke@cisco.com> = wrote:
On 9/12/13 11:31 AM, Alia = Atlas wrote:
> [Alia] I don't think that we've included locking for I2RS - so= I can't
> see how we'd have
> RS that a client cannot manipulate. =A0Whether state is removed(change= d
> back to the
> default) =A0or left, we will definitely have the ability for a Client = to
> add or change the RS
> state.

Fair enough.

>
>
> =A0 =A0 I think we have to say, to an implementor, if the Agent goes a= way, the
> =A0 =A0 RS must handle cleaning up all state installed by that Agent.<= br> >
>
> [Alia] I think that it could be either way - that the state remains bu= t
> can be overwritten
> or that the RS has to clean up the state. =A0I'm concerned that in= the RS
> cleans up the state
> case, there is no way for the Client to learn that its state has been<= br> > removed (assuming a
> failure on the part of the Agent rather than an orderly removal). =A0I= 'd
> prefer to see the state
> remain for that reason for the Agent-failure case. =A0What do you thin= k?

I think the risk of an Agent reboot allowing Client B to change Clien= t
A's state warrants the RS cleanup.

= [Alia] The risk that client B comes and changes the state after an Agent re= boot justifies the RS cleanup of that state before?? =A0Remember that Clien= t A and B aren't supposed to be overwriting each other's data. =A0W= e've defined that as an error case and that policy between the clients = should prevent it. =A0
=A0
Plus, if the Client is subscri= bed to a pub-sub bus then it could
presumably learn about an Agent cold start via a published message. =A0At that point, the client could re-establish its state to the Agent.

[Alia] Hmm, I know there was a draft discussed a= bout pub-sub methods in general - but I don't think that we've real= ly nailed down how pub-sub would work. =A0Absent anything, I'd assume t= hat the I2RS agent is whom the client registers with to get its notificatio= ns. =A0Now, if we want to have a different system being a bus (with the sca= le implications there), that might be different - but I don't think we&= #39;ve really talked about that. =A0So, my assumption is that the Agent pro= vides the notifications to Clients that have registered - and when the Agen= t reboots, there are no Clients registered to get the notifications. =A0If = you have a different model (or different thoughts on what to do for the pub= -sub), want to start that discussion (perhaps in a different thread)?
=A0
If the Client is not part of t= he bus, it could periodically connect to
the Agent and learn that it was rebooted via the protocol...yeah, this
sounds a bit like SNMP, but it seems reasonable to me.

[Alia] It doesn't sound reasonable to me... at least no= t to avoid what should be an error condition. =A0Can we discuss more? =A0Do= you have additional justification for the significant added complexity.

Regards,
Alia
=A0

Joe

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

---------------------------------------------------------------------------= -

--047d7b10cf0d6ea15704e6323c09-- From jclarke@cisco.com Thu Sep 12 10:33:25 2013 Return-Path: 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 02F3F11E81D9 for ; Thu, 12 Sep 2013 10:33:25 -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 Z5RQvcwZuX28 for ; Thu, 12 Sep 2013 10:33:15 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 3E78721F842B for ; Thu, 12 Sep 2013 10:33:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3368; q=dns/txt; s=iport; t=1379007190; x=1380216790; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=pZCzt1f3UGbTysGnEeErQOkmX3D1lBpaizyGHrA4dPE=; b=hs1lsfZP12Z9+lKocIWw+cZ8QYhxT94jTsL2BTjrfCpv9aGP588AmntU H6G2hXenl4wxIA27MFJQbcpkuEeCwpUvltVJxFMAsw7RHTGGgjwEF6uEd 5fWw5NRA/bFr9I/7Uc/WW2LUU3RZ6TszBPf7RCAJrzPjnkD0a/tYFNvck k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFACH6MVKtJV2Z/2dsb2JhbABYA4MHwWyBHRZ0giUBAQEDAXgBDgILDgQGCRYPCQMCAQIBCS4OBg0BBQIBAYd4BrsqBI4egTkQBxGEDAOXeZFzgz4ggTU X-IronPort-AV: E=Sophos;i="4.90,891,1371081600"; d="scan'208";a="258933241" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 12 Sep 2013 17:33:07 +0000 Received: from dhcp-10-150-54-134.cisco.com (dhcp-10-150-54-134.cisco.com [10.150.54.134]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r8CHX6s2032126; Thu, 12 Sep 2013 17:33:06 GMT Message-ID: <5231FAD2.1060207@cisco.com> Date: Thu, 12 Sep 2013 13:33:06 -0400 From: Joe Marcus Clarke 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: Alia Atlas References: <5231D77A.9050807@cisco.com> <5231DC28.9060600@cisco.com> <5231E14E.5020605@cisco.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "i2rs@ietf.org" 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 17:33:25 -0000 On 9/12/13 12:29 PM, Alia Atlas wrote: > [Alia] The risk that client B comes and changes the state after an Agent > reboot justifies the RS cleanup of that state before?? Remember that > Client A and B aren't supposed to be overwriting each other's data. > We've defined that as an error case and that policy between the clients > should prevent it. It's an error because the Agent says it's an error because it knows the current state. > > > Plus, if the Client is subscribed to a pub-sub bus then it could > presumably learn about an Agent cold start via a published message. At > that point, the client could re-establish its state to the Agent. > > > [Alia] Hmm, I know there was a draft discussed about pub-sub methods in > general - but I don't think that we've really nailed down how pub-sub > would work. Absent anything, I'd assume that the I2RS agent is whom the > client registers with to get its notifications. Now, if we want to have > a different system being a bus (with the scale implications there), that > might be different - but I don't think we've really talked about that. > So, my assumption is that the Agent provides the notifications to > Clients that have registered - and when the Agent reboots, there are no > Clients registered to get the notifications. If you have a different > model (or different thoughts on what to do for the pub-sub), want to > start that discussion (perhaps in a different thread)? I had envisioned that as a potential model, too. I thought TCP connections would be one way to ensure that the Client knew the pub-sub mechanism was still in place, and if that got torn down, the Client would know to renegotiate the session with the Agent. Since TCP is expensive, another model might be a UDP thing, where the Client wouldn't know if the Agent went away. But in this case, the Client would likely have a periodic check to the Agent to make sure the Agent is still healthy and still the Client would know if the Agent rebooted. A third model I thought of was a broker model in which the Agent rebooting would be a broadcast event to all subscribers. In either case, I saw that the Client would have some means of knowing the Agent went away. > > > If the Client is not part of the bus, it could periodically connect to > the Agent and learn that it was rebooted via the protocol...yeah, this > sounds a bit like SNMP, but it seems reasonable to me. > > > [Alia] It doesn't sound reasonable to me... at least not to avoid what > should be an error condition. Can we discuss more? Do you have > additional justification for the significant added complexity. One other thing I haven't raised is the operator impact. How else could an operator (i.e., owner/admin of a device) flush the I2RS changes? There might be a malicious change or just some bad state, and they want to clear that up. A restart of the Agent could do it without reloading the device. 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 ---------------------------------------------------------------------------- From mbj@tail-f.com Thu Sep 12 12:06:54 2013 Return-Path: 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 A3B4C21E8056 for ; Thu, 12 Sep 2013 12:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 N0rPhJz8Zh73 for ; Thu, 12 Sep 2013 12:06:48 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 038A511E8211 for ; Thu, 12 Sep 2013 12:06:45 -0700 (PDT) Received: from localhost (unknown [193.12.39.225]) by mail.tail-f.com (Postfix) with ESMTPSA id 120D512000BF; Thu, 12 Sep 2013 21:06:43 +0200 (CEST) Date: Thu, 12 Sep 2013 21:06:42 +0200 (CEST) Message-Id: <20130912.210642.200318150.mbj@tail-f.com> To: akatlas@gmail.com From: Martin Bjorklund In-Reply-To: References: <5231DC28.9060600@cisco.com> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: i2rs@ietf.org, jclarke@cisco.com 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 19:06:54 -0000 Alia Atlas wrote: > On Thu, Sep 12, 2013 at 11:22 AM, Joe Marcus Clarke wrote: > > I think we have to say, to an implementor, if the Agent goes away, the > > RS must handle cleaning up all state installed by that Agent. > > > > [Alia] I think that it could be either way - that the state remains but can > be overwritten > or that the RS has to clean up the state. I'm concerned that in the RS > cleans up the state > case, there is no way for the Client to learn that its state has been > removed (assuming a > failure on the part of the Agent rather than an orderly removal). I'd > prefer to see the state > remain for that reason for the Agent-failure case. What do you think? It seems to me that the important thing is that the RS state and Agent state needs to be consistent. Since the state is not persistent, at least a reboot of the entire device will remove all RS and Agent state - so this is an event that a client must be able to learn about. Depending on the implementation, there may be other events that lead to the same result (state removed). If the Agent is implemented as one OS process and keeps its state there, a restart of this process must also remove the RS state (otherwise we have an inconsistency). But I think it would be wrong to assume that all implementations do this. Maybe there are no processes at all, or maybe the Agent state is kept intact even if the Agent process restarts. As someone noted, maybe you want an explicit operation in I2RS to trigger this event - without rebooting the device, and without assuming that there is an Agent process that can be restarted. So I think it would be better to define how a client can detect that the state has been removed, and let implementations trigger this event when they have to. /martin From jclarke@cisco.com Thu Sep 12 12:24:54 2013 Return-Path: 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 ED75211E80A2 for ; Thu, 12 Sep 2013 12:24:53 -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 vz0f5d3cxWMX for ; Thu, 12 Sep 2013 12:24:44 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id DC21D11E8114 for ; Thu, 12 Sep 2013 12:24:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2483; q=dns/txt; s=iport; t=1379013884; x=1380223484; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=V3G1bE/d3bBaMmNH6xvzz0nMxz5+CWhSQ//Lz9SX+vQ=; b=cJyaECsfJmgHn2wR5NbK1yIpem86cmXPBoWDm+cWTs2sWJct3NkFRfwY 4ltvGYuqk/kH5jiv4EQENJveIFxtTtmUzX/a+4uQ9F90acNLDTCyG6/ph Zy6AY5m5fPzxrdQXIAH1aWvyBkdaRj8llx6iic0YrY7zILZ7pJ3NuIUYB k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAO0TMlKtJXHB/2dsb2JhbABYA4MHwWyBHhZ0giUBAQEEeAEOAgsOBAYJFg8JAwIBAgEJBigOBg0BBQIBAYdsAw+xRg2JJASMeYElgTkQBxGEDAOWEIFpjECFM4M+IIE1 X-IronPort-AV: E=Sophos;i="4.90,892,1371081600"; d="scan'208";a="258982374" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 12 Sep 2013 19:24:41 +0000 Received: from dhcp-10-150-54-134.cisco.com (dhcp-10-150-54-134.cisco.com [10.150.54.134]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r8CJOeRc001878; Thu, 12 Sep 2013 19:24:40 GMT Message-ID: <523214F8.1010508@cisco.com> Date: Thu, 12 Sep 2013 15:24:40 -0400 From: Joe Marcus Clarke 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: Martin Bjorklund References: <5231DC28.9060600@cisco.com> <20130912.210642.200318150.mbj@tail-f.com> In-Reply-To: <20130912.210642.200318150.mbj@tail-f.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: i2rs@ietf.org, akatlas@gmail.com 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 19:24:54 -0000 On 9/12/13 3:06 PM, Martin Bjorklund wrote: > Alia Atlas wrote: >> On Thu, Sep 12, 2013 at 11:22 AM, Joe Marcus Clarke wrote: >>> I think we have to say, to an implementor, if the Agent goes away, the >>> RS must handle cleaning up all state installed by that Agent. >>> >> >> [Alia] I think that it could be either way - that the state remains but can >> be overwritten >> or that the RS has to clean up the state. I'm concerned that in the RS >> cleans up the state >> case, there is no way for the Client to learn that its state has been >> removed (assuming a >> failure on the part of the Agent rather than an orderly removal). I'd >> prefer to see the state >> remain for that reason for the Agent-failure case. What do you think? > > It seems to me that the important thing is that the RS state and Agent > state needs to be consistent. Since the state is not persistent, at > least a reboot of the entire device will remove all RS and Agent state > - so this is an event that a client must be able to learn about. > > Depending on the implementation, there may be other events that lead > to the same result (state removed). If the Agent is implemented as > one OS process and keeps its state there, a restart of this process > must also remove the RS state (otherwise we have an inconsistency). > But I think it would be wrong to assume that all implementations do > this. Maybe there are no processes at all, or maybe the Agent state > is kept intact even if the Agent process restarts. > > As someone noted, maybe you want an explicit operation in I2RS to > trigger this event - without rebooting the device, and without > assuming that there is an Agent process that can be restarted. > > So I think it would be better to define how a client can detect that > the state has been removed, and let implementations trigger this event > when they have to. I agree with this. Would you also agree, then, that the Agent should be the keeper of the state, and when it dies, so does the state it added to the RS? Joe > > > /martin > -- 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 ---------------------------------------------------------------------------- From akatlas@gmail.com Thu Sep 12 12:28:01 2013 Return-Path: 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 7943311E81D2 for ; Thu, 12 Sep 2013 12:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 t-BFfmwCtjr0 for ; Thu, 12 Sep 2013 12:28:00 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 3307E11E80A2 for ; Thu, 12 Sep 2013 12:28:00 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id u16so560968iet.5 for ; Thu, 12 Sep 2013 12:27:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1OrILu8y/3ub4eiMoZdV8agHmmfObscwiF8S65ulaRA=; b=JBpmKTG342rCMxp7/9EtLbiw9zmsdxjC/WC2fJOwkb2TrB0xT8Rct8tfjjt1ywmyCK Wi4BDbr3HkulX3/BbP7PG4tNmXlybRXFcrqYwvBFZmsqupjXA7ReLO0vFiUsnEf9P5qo MGt1fJwXWn2+P6usaYHeQrboit1uaRdZvyHeZ/gjA/1YEYY6MDx/mI1pE/ZTN5NCj+G6 d4Y3M0p718lfbsuWo6B3h8ydmF+Kkfx9KD7oofTFo66qzWv7yXynFgn6U+sN/tdTz4NN ZWHZ3pcpZTkU8V318+U4NhzYQEDhLumHzIioDh5Au6lUIVnla/41O8W8qKGXvSo0St9X AmuA== MIME-Version: 1.0 X-Received: by 10.50.111.228 with SMTP id il4mr4508748igb.1.1379014079810; Thu, 12 Sep 2013 12:27:59 -0700 (PDT) Received: by 10.64.13.145 with HTTP; Thu, 12 Sep 2013 12:27:59 -0700 (PDT) In-Reply-To: <20130912.210642.200318150.mbj@tail-f.com> References: <5231DC28.9060600@cisco.com> <20130912.210642.200318150.mbj@tail-f.com> Date: Thu, 12 Sep 2013 15:27:59 -0400 Message-ID: From: Alia Atlas To: Martin Bjorklund Content-Type: multipart/alternative; boundary=047d7b3a9c085e256004e634bcfb Cc: "i2rs@ietf.org" , Joe Marcus Clarke 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 19:28:01 -0000 --047d7b3a9c085e256004e634bcfb Content-Type: text/plain; charset=ISO-8859-1 Hi Martin, in-line On Thu, Sep 12, 2013 at 3:06 PM, Martin Bjorklund wrote: > Alia Atlas wrote: > > On Thu, Sep 12, 2013 at 11:22 AM, Joe Marcus Clarke >wrote: > > > I think we have to say, to an implementor, if the Agent goes away, the > > > RS must handle cleaning up all state installed by that Agent. > > > > > > > [Alia] I think that it could be either way - that the state remains but > can > > be overwritten > > or that the RS has to clean up the state. I'm concerned that in the RS > > cleans up the state > > case, there is no way for the Client to learn that its state has been > > removed (assuming a > > failure on the part of the Agent rather than an orderly removal). I'd > > prefer to see the state > > remain for that reason for the Agent-failure case. What do you think? > > It seems to me that the important thing is that the RS state and Agent > state needs to be consistent. Since the state is not persistent, at > least a reboot of the entire device will remove all RS and Agent state > - so this is an event that a client must be able to learn about. > [Alia] Implementations will vary, but my assumption has been that, conceptually, the I2RS Agent stores the client identity and so on associated with data that is written - while the RS continues to store just the subset of what was written. > Depending on the implementation, there may be other events that lead > to the same result (state removed). If the Agent is implemented as > one OS process and keeps its state there, a restart of this process > must also remove the RS state (otherwise we have an inconsistency). > But I think it would be wrong to assume that all implementations do > this. Maybe there are no processes at all, or maybe the Agent state > is kept intact even if the Agent process restarts. > > As someone noted, maybe you want an explicit operation in I2RS to > trigger this event - without rebooting the device, and without > assuming that there is an Agent process that can be restarted. > > So I think it would be better to define how a client can detect that > the state has been removed, and let implementations trigger this event > when they have to. > [Alia] I agree that building in the ability to notify a client that all I2RS state or all of that client's state has been removed is useful. However, doing so outside of the I2RS agent seems problematic... Alia --047d7b3a9c085e256004e634bcfb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Martin,

in-line

On Thu, Sep 12, 2013 at 3:06 PM, Martin Bjorklund <mbj@tail-f.co= m> wrote:
Alia Atlas <akatlas@gmail.com> wrote:
> On Thu, Sep 12, 2013 at 11:22 AM, Joe Marcus Clarke <jclarke@cisco.com>wrote:
> > I think we have to say, to an implementor= , if the Agent goes away, the
> > RS must handle cleaning up all state installed by that Agent.
> >
>
> [Alia] I think that it could be either way - that the state remains bu= t can
> be overwritten
> or that the RS has to clean up the state. =A0I'm concerned that in= the RS
> cleans up the state
> case, there is no way for the Client to learn that its state has been<= br> > removed (assuming a
> failure on the part of the Agent rather than an orderly removal). =A0I= 'd
> prefer to see the state
> remain for that reason for the Agent-failure case. =A0What do you thin= k?

It seems to me that the important thing is that the RS state and Agen= t
state needs to be consistent. =A0Since the state is not persistent, at
least a reboot of the entire device will remove all RS and Agent state
- so this is an event that a client must be able to learn about.

[Alia] Implementations will vary, but my assumpti= on has been that, conceptually,
the I2RS Agent stores the client = identity and so on associated with data that is
written - while the RS continues to store just the subset of what was = written.
=A0
Depending on the= implementation, there may be other events that lead
to the same result (state removed). =A0If the Agent is implemented as
one OS process and keeps its state there, a restart of this process
must also remove the RS state (otherwise we have an inconsistency).
But I think it would be wrong to assume that all implementations do
this. =A0Maybe there are no processes at all, or maybe the Agent state
is kept intact even if the Agent process restarts.

As someone noted, maybe you want an explicit operation in I2RS to
trigger this event - without rebooting the device, and without
assuming that there is an Agent process that can be restarted.

So I think it would be better to define how a client can detect that
the state has been removed, and let implementations trigger this event
when they have to.

[Alia] I agree that = building in the ability to notify a client that all I2RS state
or= all of that client's state has been removed is useful. =A0However, doi= ng so
outside of the I2RS agent seems problematic... =A0

Alia
--047d7b3a9c085e256004e634bcfb-- From akatlas@gmail.com Thu Sep 12 12:49:32 2013 Return-Path: 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 7D9F011E8249 for ; Thu, 12 Sep 2013 12:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 YnNgGgCmAGLd for ; Thu, 12 Sep 2013 12:49:31 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF8311E824F for ; Thu, 12 Sep 2013 12:49:31 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id to1so655419ieb.9 for ; Thu, 12 Sep 2013 12:49:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zIwsuq1fwlSmZWTT64Uv1ZXabdF7WvYiUlCeQC4hxGQ=; b=m7tqhZor6OBkSFanl/I8JfDM6Bl1WUvOtoJRDVqcr1eeJLIcvnU/uabKV95fMlQZ2v 6mYVzff66eHpLCv7e9VBqCBtNI3DX5aSnkbdF2bV70nHmGBYAsXZW9uQQg5a38lbo86M 9JrrWqlZO0cj37HgmiSS0iPK+sQqJ79goUaT02N2KFN7Yw0ALhKvyY9wOx64rZDP2UEB S21oMt4HwUmIUPShcjTLzdPOTUFeaTil4MUf6IhI/v3BX/mmyQBTvpKRTdJc3X2DEWK7 DeaaLhkXIVF05wHTFBFj4sQq6mbim4PZRrUOX10/Soowyrw5caLP0yAhvEOoVxlJgimr 0vZg== MIME-Version: 1.0 X-Received: by 10.50.128.137 with SMTP id no9mr2268806igb.36.1379015370701; Thu, 12 Sep 2013 12:49:30 -0700 (PDT) Received: by 10.64.13.145 with HTTP; Thu, 12 Sep 2013 12:49:30 -0700 (PDT) In-Reply-To: <5231FAD2.1060207@cisco.com> References: <5231D77A.9050807@cisco.com> <5231DC28.9060600@cisco.com> <5231E14E.5020605@cisco.com> <5231FAD2.1060207@cisco.com> Date: Thu, 12 Sep 2013 15:49:30 -0400 Message-ID: From: Alia Atlas To: Joe Marcus Clarke Content-Type: multipart/alternative; boundary=047d7b10cf0d4f836904e635098b Cc: "i2rs@ietf.org" 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 19:49:32 -0000 --047d7b10cf0d4f836904e635098b Content-Type: text/plain; charset=ISO-8859-1 Hi Joe, In-line responses again. On Thu, Sep 12, 2013 at 1:33 PM, Joe Marcus Clarke wrote: > On 9/12/13 12:29 PM, Alia Atlas wrote: > > [Alia] The risk that client B comes and changes the state after an Agent > > reboot justifies the RS cleanup of that state before?? Remember that > > Client A and B aren't supposed to be overwriting each other's data. > > We've defined that as an error case and that policy between the clients > > should prevent it. > > It's an error because the Agent says it's an error because it knows the > current state. > [Alia] But we (the WG) said that it was an error because we expect coordination between the applications to avoid multiple writers of the same data. It's not an error because the Agent says so - the Agent would just report back what happened (successful write or fail due to higher priority). > > > > > > Plus, if the Client is subscribed to a pub-sub bus then it could > > presumably learn about an Agent cold start via a published message. > At > > that point, the client could re-establish its state to the Agent. > > > > > > [Alia] Hmm, I know there was a draft discussed about pub-sub methods in > > general - but I don't think that we've really nailed down how pub-sub > > would work. Absent anything, I'd assume that the I2RS agent is whom the > > client registers with to get its notifications. Now, if we want to have > > a different system being a bus (with the scale implications there), that > > might be different - but I don't think we've really talked about that. > > So, my assumption is that the Agent provides the notifications to > > Clients that have registered - and when the Agent reboots, there are no > > Clients registered to get the notifications. If you have a different > > model (or different thoughts on what to do for the pub-sub), want to > > start that discussion (perhaps in a different thread)? > > I had envisioned that as a potential model, too. I thought TCP > connections would be one way to ensure that the Client knew the pub-sub > mechanism was still in place, and if that got torn down, the Client > would know to renegotiate the session with the Agent. > > Since TCP is expensive, another model might be a UDP thing, where the > Client wouldn't know if the Agent went away. But in this case, the > Client would likely have a periodic check to the Agent to make sure the > Agent is still healthy and still the Client would know if the Agent > rebooted. > [Alia] As Joel had said, I think we're trying to avoid the need for persistent connections just to confirm liveness. It's a heavy-handed way to do it. That said, we could use a mechanism to determine if the RS is up and if the associated Agent is up. Of course, there can be multiple Agents per RS - each supporting different services or such. For a router reboot, a Client that is learning topology would hear very quickly that a router has failed or appeared. [Alia] So - developing a liveness detection mechanism is useful. But what would be useful is the ability for the RS to notify interested clients on a failure. Otherwise, what frequency would suffice for checking - when traffic can be being actively dropped or misrouted if the Agent has failed. Also - are we designing for the error-case of a crashed Agent rather than the normal case of a gracefully shut down Agent? A third model I thought of was a broker model in which the Agent > rebooting would be a broadcast event to all subscribers. > [Alia] I've been assuming, I guess, that Clients would hear about router failures via the topology DM based from the IGP. > In either case, I saw that the Client would have some means of knowing > the Agent went away. > [Alia] I can see that if the Client knew that the Agent went away (ungracefully), that having the associated RS clean up state would be fine. I haven't yet heard a fully baked design where the client would know rapidly. We (you?) could come up with one, but that needs to be written down and agreed to. Without that, I hear that the Client's state might suddenly disappear without the Client being able to tell - and am much more comfortable leaving it there to be removed either via CLI or to be read and then written again by the Client when it reconnects. [Alia] To be clear, I didn't have an opinion about this aspect before you raised the question - and I think that exploring the reasonable solutions and requirements for them is a good idea. > > > > > > If the Client is not part of the bus, it could periodically connect > to > > the Agent and learn that it was rebooted via the protocol...yeah, > this > > sounds a bit like SNMP, but it seems reasonable to me. > > > > > > [Alia] It doesn't sound reasonable to me... at least not to avoid what > > should be an error condition. Can we discuss more? Do you have > > additional justification for the significant added complexity. > > One other thing I haven't raised is the operator impact. How else could > an operator (i.e., owner/admin of a device) flush the I2RS changes? > There might be a malicious change or just some bad state, and they want > to clear that up. A restart of the Agent could do it without reloading > the device. > [Alia] Why wouldn't using the CLI to flush the I2RS changes work? Also, that is a graceful restart of the Agent - where the Agent can tell each Client that all its written data has been preempted because the Agent is rebooting. I'm also concerned that the behavior make sense for if/when the Agent fails. I could be persuaded not to worry about that (Agents shouldn't crash) - but I'd prefer not to mandate complexity for that case. Alia > > 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 > > > ---------------------------------------------------------------------------- > --047d7b10cf0d4f836904e635098b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Joe,

In-line responses again. =A0

On Thu, Sep 12, = 2013 at 1:33 PM, Joe Marcus Clarke <jclarke@cisco.com> wrote= :
On 9/12/13 12:29 PM, Alia Atlas wrote: > [Alia] The risk that client B comes and changes the state after an Age= nt
> reboot justifies the RS cleanup of that state before?? =A0Remember tha= t
> Client A and B aren't supposed to be overwriting each other's = data.
> =A0We've defined that as an error case and that policy between the= clients
> should prevent it.

It's an error because the Agent says it's an error because it= knows the
current state.

[Alia] But we (the WG) s= aid that it was an error because we expect coordination
between t= he applications to avoid multiple writers of the same data. =A0It's not= an
error because the Agent says so - the Agent would just report back wha= t happened
(successful write or fail due to higher priority).
=A0
>
>
> =A0 =A0 Plus, if the Client is subscribed to a pub-sub bus then it cou= ld
> =A0 =A0 presumably learn about an Agent cold start via a published mes= sage. =A0At
> =A0 =A0 that point, the client could re-establish its state to the Age= nt.
>
>
> [Alia] Hmm, I know there was a draft discussed about pub-sub methods i= n
> general - but I don't think that we've really nailed down how = pub-sub
> would work. =A0Absent anything, I'd assume that the I2RS agent is = whom the
> client registers with to get its notifications. =A0Now, if we want to = have
> a different system being a bus (with the scale implications there), th= at
> might be different - but I don't think we've really talked abo= ut that.
> =A0So, my assumption is that the Agent provides the notifications to > Clients that have registered - and when the Agent reboots, there are n= o
> Clients registered to get the notifications. =A0If you have a differen= t
> model (or different thoughts on what to do for the pub-sub), want to > start that discussion (perhaps in a different thread)?

I had envisioned that as a potential model, too. =A0I thought TCP
connections would be one way to ensure that the Client knew the pub-sub
mechanism was still in place, and if that got torn down, the Client
would know to renegotiate the session with the Agent.

Since TCP is expensive, another model might be a UDP thing, where the
Client wouldn't know if the Agent went away. =A0But in this case, the Client would likely have a periodic check to the Agent to make sure the
Agent is still healthy and still the Client would know if the Agent
rebooted.

[Alia] As Joel had said, I th= ink we're trying to avoid the need for persistent
connections= just to confirm liveness. =A0It's a heavy-handed way to do it. =A0That= said,
we could use a mechanism to determine if the RS is up and if the assoc= iated
Agent is up. =A0Of course, there can be multiple Agents per= RS - each supporting
different services or such. For a router re= boot, a Client that is learning topology
would hear very quickly that a router has failed or appeared.

[Alia] So - developing a liveness detection mechanism is u= seful. =A0But what would
be useful is the ability for the RS to n= otify interested clients on a failure. =A0Otherwise,
what frequency would suffice for checking - when traffic can be being = actively dropped
or misrouted if the Agent has failed. =A0 =A0Als= o - are we designing for the error-case of
a crashed Agent rather= than the normal case of a gracefully shut down Agent?

A third model I thought of was a broker mod= el in which the Agent
rebooting would be a broadcast event to all subscribers.

[Alia] I've been assuming, I guess, that Clients woul= d hear about router failures via
the topology DM based from the I= GP. =A0=A0
=A0
In either case, I saw that the Client would = have some means of knowing
the Agent went away.

[Alia] I can see t= hat if the Client knew that the Agent went away (ungracefully), that
<= div>having the associated RS clean up state would be fine. =A0I haven't= yet heard a fully baked
design where the client would know rapidly. =A0We (you?) could come up= with one, but
that needs to be written down and agreed to. =A0Wi= thout that, I hear that the Client's state
might suddenly dis= appear without the Client being able to tell - and am much more comfortable=
leaving it there to be removed either via CLI or to be read and then w= ritten again by the Client
when it reconnects.
=A0
[Alia] To be clear, I didn't have an opinion about this aspect be= fore you raised the question -
and I think that exploring the reasonable solutions and requirements f= or them is a good idea.


>
>
> =A0 =A0 If the Client is not part of the bus, it could periodically co= nnect to
> =A0 =A0 the Agent and learn that it was rebooted via the protocol...ye= ah, this
> =A0 =A0 sounds a bit like SNMP, but it seems reasonable to me.
>
>
> [Alia] It doesn't sound reasonable to me... at least not to avoid = what
> should be an error condition. =A0Can we discuss more? =A0Do you have > additional justification for the significant added complexity.

One other thing I haven't raised is the operator impact. =A0How e= lse could
an operator (i.e., owner/admin of a device) flush the I2RS changes?
There might be a malicious change or just some bad state, and they want
to clear that up. =A0A restart of the Agent could do it without reloading the device.

[Alia] =A0Why wouldn't = using the CLI to flush the I2RS changes work? =A0Also, that
is a = graceful restart of the Agent - where the Agent can tell each Client that a= ll=A0
its written data has been preempted because the Agent is rebooting. = =A0I'm also
concerned that the behavior make sense for if/whe= n the Agent fails. =A0I could be
persuaded not to worry about tha= t (Agents shouldn't crash) - but I'd prefer not to
mandate complexity for that case.

Alia
<= div>=A0

Joe

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

---------------------------------------------------------------------------= -

--047d7b10cf0d4f836904e635098b-- From mbj@tail-f.com Thu Sep 12 13:06:33 2013 Return-Path: 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 AE08C21E80F2 for ; Thu, 12 Sep 2013 13:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 P0zEODysQejd for ; Thu, 12 Sep 2013 13:06:22 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 3E64B11E80F4 for ; Thu, 12 Sep 2013 13:06:21 -0700 (PDT) Received: from localhost (unknown [193.12.39.225]) by mail.tail-f.com (Postfix) with ESMTPSA id 28C411200054; Thu, 12 Sep 2013 22:06:20 +0200 (CEST) Date: Thu, 12 Sep 2013 22:06:19 +0200 (CEST) Message-Id: <20130912.220619.255855318.mbj@tail-f.com> To: jclarke@cisco.com From: Martin Bjorklund In-Reply-To: <523214F8.1010508@cisco.com> References: <20130912.210642.200318150.mbj@tail-f.com> <523214F8.1010508@cisco.com> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: i2rs@ietf.org, akatlas@gmail.com 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 20:06:33 -0000 Joe Marcus Clarke wrote: > On 9/12/13 3:06 PM, Martin Bjorklund wrote: > > Alia Atlas wrote: > >> On Thu, Sep 12, 2013 at 11:22 AM, Joe Marcus Clarke > >> wrote: > >>> I think we have to say, to an implementor, if the Agent goes away, the > >>> RS must handle cleaning up all state installed by that Agent. > >>> > >> > >> [Alia] I think that it could be either way - that the state remains but can > >> be overwritten > >> or that the RS has to clean up the state. I'm concerned that in the RS > >> cleans up the state > >> case, there is no way for the Client to learn that its state has been > >> removed (assuming a > >> failure on the part of the Agent rather than an orderly removal). I'd > >> prefer to see the state > >> remain for that reason for the Agent-failure case. What do you think? > > > > It seems to me that the important thing is that the RS state and Agent > > state needs to be consistent. Since the state is not persistent, at > > least a reboot of the entire device will remove all RS and Agent state > > - so this is an event that a client must be able to learn about. > > > > Depending on the implementation, there may be other events that lead > > to the same result (state removed). If the Agent is implemented as > > one OS process and keeps its state there, a restart of this process > > must also remove the RS state (otherwise we have an inconsistency). > > But I think it would be wrong to assume that all implementations do > > this. Maybe there are no processes at all, or maybe the Agent state > > is kept intact even if the Agent process restarts. > > > > As someone noted, maybe you want an explicit operation in I2RS to > > trigger this event - without rebooting the device, and without > > assuming that there is an Agent process that can be restarted. > > > > So I think it would be better to define how a client can detect that > > the state has been removed, and let implementations trigger this event > > when they have to. > > I agree with this. Would you also agree, then, that the Agent should be > the keeper of the state, and when it dies, so does the state it added to > the RS? I agree that it should be a valid implementation strategy to let the Agent keep the state, and thus if it dies, such an implementation must remove the state state it added to the RS. But I don't think all implementations have to do it this way. All implementations must do: "if i2rs state gone then also rs state gone". /martin From sriganeshkini@gmail.com Thu Sep 12 21:41:58 2013 Return-Path: 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 2337E11E810F for ; Thu, 12 Sep 2013 21:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 kcTddbwg6aie for ; Thu, 12 Sep 2013 21:41:56 -0700 (PDT) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 745F811E8110 for ; Thu, 12 Sep 2013 21:41:56 -0700 (PDT) Received: by mail-pd0-f179.google.com with SMTP id v10so741117pde.10 for ; Thu, 12 Sep 2013 21:41:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=qo7oS+EF8lpqiYdcq0Fmq0Qy413q2UmHM1PBIS1b13c=; b=ewVrn8CPrIHWgmxJWv9Sor92rTg0A/rr2RtqjxdyWm0HBEmyXivvSH1LTUx5FME0lK yUmc7AlN/QuyDsJsUH4wURauW6gLOBzuMU678Nk2VcY5sBMY12CcWm0AP/njQo5+4+IW Q/Y4fRYg0WQNRwuXg3rh5K1sWe1J95WHelrgk6+5lijR6inCaO8OsTFAJAfaWDyh+5i3 b3K4T82NSFJbkNsVKHBtb/vW8DEb2todFH32JwQGhCl2Tjbr34xgdj96+IGqOyIIhvKx KXarwoCOp28QakOK6fFbigdCoYcEiZTWudc4FOEwRKJGu8XOYeihqprunp83JNeHf853 0KqA== X-Received: by 10.68.179.65 with SMTP id de1mr11284597pbc.73.1379047315284; Thu, 12 Sep 2013 21:41:55 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.70.13.129 with HTTP; Thu, 12 Sep 2013 21:41:25 -0700 (PDT) In-Reply-To: References: From: Sriganesh Kini Date: Thu, 12 Sep 2013 21:41:25 -0700 X-Google-Sender-Auth: EU5AXdkZ5xKua4R93BxZGvj7ugk Message-ID: To: Alia Atlas Content-Type: multipart/alternative; boundary=047d7bacbd3a5b2c8204e63c79cf Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Architecture Discussion 4: templates for Policy and QoS mechanisms X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 04:41:58 -0000 --047d7bacbd3a5b2c8204e63c79cf Content-Type: text/plain; charset=UTF-8 Hi Alia, As part of of evolving the RIB IM the authors are looking into routing-policies and policy-based-routing (PBR) IMs. As part of the PBR IMs we are discussing whether the QoS IMs (policing, rate-limiting, queueing ... etc) should be in scope and what they should include. As you quoted from the arch doc, these could vary widely across implementations and we are discussing what the core set may be. We have not finalized this yet and it is possible that the QoS IM would be in a separate draft. Also, as part of discussing routing-policies we have considered making templates (named objects) that can be re-used (e.g. across various RIBs). These objects should be at the top-level of the IMs. It would be useful to do this in a manner that is consistent across various IMs. Thanks - Sri On Thu, Sep 12, 2013 at 7:55 AM, Alia Atlas wrote: > In draft-ietf-i2rs-architecture-00 Sec 5.4.4: > > " Many network elements have separate policy and QoS mechanisms, > > including knobs which affect local path computation and queue control > capabilities. These capabilities vary widely across implementations, > and I2RS cannot model the full range of information collection or > manipulation of these attributes. A core set does need to be > included in the I2RS data models and in the expected interfaces > between the I2RS Agent and the network element, in order to provide > basic capabilities and the hooks for future extensibility. > [[Editor's note: This requires more discussion in the working > group.]]" > > > I would like to start that discussion now. > > > Personally, I have not seen or heard much discussion or any information-models > > around these templates. What do people think is necessary? How should this > > part of the architecture draft change? > > > Thanks, > > Alia (WG-Chair hat off) > > > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > --047d7bacbd3a5b2c8204e63c79cf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Alia,

As part of of evolving the= RIB IM the authors are looking into routing-policies and policy-based-rout= ing (PBR) IMs. As part of the PBR IMs we are discussing whether the QoS IMs= (policing, rate-limiting, queueing ... etc) should be in scope and what th= ey should include. As you quoted from the arch doc, these could vary widely= across implementations and we are discussing what the core set may be. We = have not finalized this yet and it is possible that the QoS IM would be in = a separate draft.

Also, as part of discussing routing-policies we have conside= red making templates (named objects) that can be re-used (e.g. across vario= us RIBs). These objects should be at the top-level of the IMs. It would be = useful to do this in a manner that is consistent across various IMs.

Thanks
- Sri


On Thu, Sep 12, 2013= at 7:55 AM, Alia Atlas <akatlas@gmail.com> wrote:
In draft-ietf-i2rs-architecture-00 Sec 5.4.4:
<= font face=3D"arial, helvetica, sans-serif">
" Many network elements have separate policy and QoS mechanisms,
   including knobs which affect local path computation and=
 queue control
   capabilities.  These capabilities vary widely across implementations,
   and I2RS cannot model the full range of information collection or
   manipulation of these attributes.  A core set does need to be
   included in the I2RS data models and in the expected interfaces
   between the I2RS Agent and the network element, in order to provide
   basic capabilities and the hooks for future extensibility.
   [[Editor's note: This requires more discussion in the working
   group.]]"

I would like to start that discussion now.  

Personally, I have not seen or heard much discussion or an=
y information-models

around these templates.  What d=
o people think is necessary?  How should this
=
part of the architecture draft change?

Thanks,
Alia (WG-Chair hat off)

<=
/font>

_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs


--047d7bacbd3a5b2c8204e63c79cf-- From jclarke@cisco.com Thu Sep 12 21:58:41 2013 Return-Path: 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 0012021F99E7 for ; Thu, 12 Sep 2013 21:58:40 -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 aWkmXGa45Lyi for ; Thu, 12 Sep 2013 21:58:35 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id F115D21F99CD for ; Thu, 12 Sep 2013 21:58:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4824; q=dns/txt; s=iport; t=1379048311; x=1380257911; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=p6D2sWCBmGgoLU33xLNf/PhMP9CpYLnNeGwQlzkyqRo=; b=d58DwbRKgvsRcy2Z/2AJU3iqvCT1IM0F4SHdZ85b4KKEp3SI5hJ0hlx6 ZzyTFS4YLa4Y1fKsLnKGnMfjybDFlilNKMAv8hM/UK6LiwlosDcEnvQ1M diwUQ0r1ZvWZfT2Wyvq5RevhI7F9wS9Aw8Wc2bBx+qgVIz8uKaCbNvl9U 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFALaaMlKtJXG+/2dsb2JhbABYA4MHwXiBHhZ0giUBAQEDASdABgsBBQkCCw4EBgkWDwkDAgECAQkuDgYNAQUCAQGHeQa6eASOH4E5EAcRhA0Dl3qRc4M/IIE1 X-IronPort-AV: E=Sophos;i="4.90,896,1371081600"; d="scan'208";a="259175107" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 13 Sep 2013 04:58:30 +0000 Received: from rtp-jclarke-8919.cisco.com (rtp-jclarke-8919.cisco.com [10.117.46.170]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r8D4wTTG011362; Fri, 13 Sep 2013 04:58:29 GMT Message-ID: <52329B75.2080703@cisco.com> Date: Fri, 13 Sep 2013 00:58:29 -0400 From: Joe Marcus Clarke 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: Alia Atlas References: <5231D77A.9050807@cisco.com> <5231DC28.9060600@cisco.com> <5231E14E.5020605@cisco.com> <5231FAD2.1060207@cisco.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "i2rs@ietf.org" 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 04:58:41 -0000 On 9/12/13 3:49 PM, Alia Atlas wrote: > [Alia] But we (the WG) said that it was an error because we expect > coordination > between the applications to avoid multiple writers of the same data. > It's not an > error because the Agent says so - the Agent would just report back what > happened > (successful write or fail due to higher priority). My point was that the Agent knows the priority. This isn't passed to the RS. > [Alia] As Joel had said, I think we're trying to avoid the need for > persistent > connections just to confirm liveness. It's a heavy-handed way to do it. > That said, > we could use a mechanism to determine if the RS is up and if the associated > Agent is up. Of course, there can be multiple Agents per RS - each > supporting > different services or such. For a router reboot, a Client that is > learning topology > would hear very quickly that a router has failed or appeared. > > [Alia] So - developing a liveness detection mechanism is useful. But > what would > be useful is the ability for the RS to notify interested clients on a > failure. Otherwise, > what frequency would suffice for checking - when traffic can be being > actively dropped > or misrouted if the Agent has failed. Also - are we designing for the > error-case of > a crashed Agent rather than the normal case of a gracefully shut down Agent? I was raising the point of both. In the graceful case, the Agent clears all state and notifies all Clients. But the crash is a possibility, and we should stipulate what should happen to state. I don't think we want the RS doing anything to the Clients directly. I think perhaps an Agent->Client heartbeat is a useful thing if the Client asks to be notified about changes. > > A third model I thought of was a broker model in which the Agent > rebooting would be a broadcast event to all subscribers. > > > [Alia] I've been assuming, I guess, that Clients would hear about router > failures via > the topology DM based from the IGP. Router failure of Agent failure? > > > In either case, I saw that the Client would have some means of knowing > the Agent went away. > > > [Alia] I can see that if the Client knew that the Agent went away > (ungracefully), that > having the associated RS clean up state would be fine. I haven't yet > heard a fully baked > design where the client would know rapidly. We (you?) could come up > with one, but > that needs to be written down and agreed to. Without that, I hear that > the Client's state > might suddenly disappear without the Client being able to tell - and am > much more comfortable > leaving it there to be removed either via CLI or to be read and then > written again by the Client > when it reconnects. I've been kicking around the idea of a pub-sub "heartbeat." This would give the Client awareness of the Agent's "thereness." If the heartbeat carried a boot count, the Client might not need for multiple dropped heartbeats before reapplying state. I don't know if this is an ideal way to confirm liveness of the agent, though I'm happy to propose it more formally. I think the exact approach would depend on what the pub-sub mechanism is determined to be. > One other thing I haven't raised is the operator impact. How else could > an operator (i.e., owner/admin of a device) flush the I2RS changes? > There might be a malicious change or just some bad state, and they want > to clear that up. A restart of the Agent could do it without reloading > the device. > > > [Alia] Why wouldn't using the CLI to flush the I2RS changes work? It would. I didn't realize you were okay with a graceful restart of the Agent purging all RS state for which it is responsible. If you are, then that is handled. > Also, that > is a graceful restart of the Agent - where the Agent can tell each > Client that all > its written data has been preempted because the Agent is rebooting. I'm > also > concerned that the behavior make sense for if/when the Agent fails. I > could be > persuaded not to worry about that (Agents shouldn't crash) - but I'd > prefer not to > mandate complexity for that case. I think we should. Because if there is a crash from the Agent, how then can an admin purge state? There would no longer be a clean way to do this. I'm trying to think what an operator might like here. 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 ---------------------------------------------------------------------------- From jmh@joelhalpern.com Fri Sep 13 05:19:23 2013 Return-Path: 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 7763911E8186 for ; Fri, 13 Sep 2013 05:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 pOv7iO-jVHvB for ; Fri, 13 Sep 2013 05:19:16 -0700 (PDT) Received: from mailb1.tigertech.net (mailb1.tigertech.net [208.80.4.153]) by ietfa.amsl.com (Postfix) with ESMTP id B65F311E81ED for ; Fri, 13 Sep 2013 05:19:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb1.tigertech.net (Postfix) with ESMTP id 9C19CD40524 for ; Fri, 13 Sep 2013 05:19:15 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at mailb1.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [192.165.183.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb1.tigertech.net (Postfix) with ESMTPSA id 92484D4025C for ; Fri, 13 Sep 2013 05:19:14 -0700 (PDT) Message-ID: <523302BF.4040701@joelhalpern.com> Date: Fri, 13 Sep 2013 08:19:11 -0400 From: "Joel M. Halpern" 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: "i2rs@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [i2rs] RIB Model draft X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 12:19:23 -0000 I support adoption of this draft. I do have some questions, brought to my attention when some of my folks read the draft. Given that metrics are not comparable between routing protocols, or even between distinct instances of routing protocols, why are the metrics in the general RIB model instead of the protocol specific models? Similarly, why is AS Path in this model, rather than in the BGP model? Whether the decision is implemented in BGP or a common RIB model would seem implementation specific, but from a model perspective it seems to be a BGP-specific property rather than a generic RIB property. The load balancing attributes seem to reflect a particular implementation strategy. While a not unreasonable strategy, the modeling seems pretty implementation specific. This applies to both the specifics of load balance weight and the interaction of that weight with protection preference. Having nodecrementTTL has a general nexthop attribute seems a mistake. In fact, having a next hop with no decrement seems very dangerous, since one could have a looping tunnel chain with no decrementing. Is this really something we want in the model? (I can't stop someone from doing it in an implementation.) While the model should permit handling the TTL propagation into and out of tunnels, it should not mandate support for specific modes. How do we indicate that support for things like the NO_PROPAGATE_TTL flag is optional, or conversely always set? Minor: I presume that the cardinality of 0 is allowed in the relationship between route and nexthop-list to reflect incomplete route entries? If so, shouldn't the text say so? Nit: figure 2 should include multicast. Yours, Joel From russw@riw.us Fri Sep 13 07:48:05 2013 Return-Path: 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 83C4011E8113 for ; Fri, 13 Sep 2013 07:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 lezHIgj-VSXa for ; Fri, 13 Sep 2013 07:47:59 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 79F5F11E80F6 for ; Fri, 13 Sep 2013 07:47:59 -0700 (PDT) Received: from [156.39.10.22] (helo=[10.45.191.120]) by da31.namelessnet.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1VKUf5-0004Dj-3y; Fri, 13 Sep 2013 07:47:55 -0700 References: <5231D77A.9050807@cisco.com> <5231DC28.9060600@cisco.com> <5231E14E.5020605@cisco.com> <5231FAD2.1060207@cisco.com> <52329B75.2080703@cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: <52329B75.2080703@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <006EB573-5BA1-4DA3-8EB6-6E8DD98AE48A@riw.us> X-Mailer: iPad Mail (10B329) From: Russ White Date: Fri, 13 Sep 2013 07:47:55 -0700 To: Joe Marcus Clarke X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Cc: "i2rs@ietf.org" , Alia Atlas 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 14:48:05 -0000 > I think we should. Because if there is a crash from the Agent, how then > can an admin purge state? There would no longer be a clean way to do > this. I'm trying to think what an operator might like here. IMHO: - no heartbeat or any other persistent connection - if the controller crashes, on startup up it should connect to all the clie= nts it knows about (some controller state needs to be persistent across rebo= ot) and send at least one null or other command - each packet/command the controller sends contains a "boot count," or "sess= ion I'd," or something like that; this must increment each time the controll= er reboots or resets its state - if a client receives a command/packet with the "wrong" session I'd (or wha= tever it's called) it clears any state associated with that controller This doesn't require the agent to keep persistent state, but allows current s= tate to remain without persistent communication. It's possible to design a g= raceful restart mechanism (like bgp), but lets leave it out of the discussio= n until we get a better handle on what the protocols and models actually loo= k like. We can speculate, but the devil is in the details in graceful restar= t. :-) Russ <>< russw@riw.us ?@?.com (engineer without a portfolio)= From russw@riw.us Fri Sep 13 07:50:58 2013 Return-Path: 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 D26BA11E8213 for ; Fri, 13 Sep 2013 07:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 QJvfNaEZMsWY for ; Fri, 13 Sep 2013 07:50:47 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id ACE9811E80F6 for ; Fri, 13 Sep 2013 07:50:41 -0700 (PDT) Received: from [156.39.10.22] (helo=[10.45.191.120]) by da31.namelessnet.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1VKUhf-0004Tc-Uh; Fri, 13 Sep 2013 07:50:36 -0700 References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-409E7E3F-FC54-46F2-B7A5-2AAE0A3593A3 Content-Transfer-Encoding: 7bit Message-Id: <42DC10E7-3A2A-4BCF-BD61-7C38134B7E37@riw.us> X-Mailer: iPad Mail (10B329) From: Russ White Date: Fri, 13 Sep 2013 07:50:36 -0700 To: Alia Atlas X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Architecture Discussion 4: templates for Policy and QoS mechanisms X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 14:50:58 -0000 --Apple-Mail-409E7E3F-FC54-46F2-B7A5-2AAE0A3593A3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I'm a little worried about trying to characterize every possible QoS model o= ut there... Seems like we should just stick to some standard model, and let i= mplementors map between that and the reality. :-) Russ <>< russw@riw.us ?@?.com (engineer without a portfolio) On Sep 12, 2013, at 7:55 AM, Alia Atlas wrote: > In draft-ietf-i2rs-architecture-00 Sec 5.4.4: >=20 > " Many network elements have separate policy and QoS mechanisms, > including knobs which affect local path computation and queue control > capabilities. These capabilities vary widely across implementations, > and I2RS cannot model the full range of information collection or > manipulation of these attributes. A core set does need to be > included in the I2RS data models and in the expected interfaces > between the I2RS Agent and the network element, in order to provide > basic capabilities and the hooks for future extensibility. > [[Editor's note: This requires more discussion in the working > group.]]" >=20 > I would like to start that discussion now. =20 >=20 > Personally, I have not seen or heard much discussion or any information-mo= dels > around these templates. What do people think is necessary? How should th= is > part of the architecture draft change? >=20 > Thanks, > Alia (WG-Chair hat off) >=20 >=20 >=20 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs --Apple-Mail-409E7E3F-FC54-46F2-B7A5-2AAE0A3593A3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

I'm a little worried ab= out trying to characterize every possible QoS model out there... Seems like w= e should just stick to some standard model, and let implementors map between= that and the reality.

:-)

Russ

<><
?@?.com (engineer without a portfolio)

On Sep 12, 2013, at 7:55 AM, Alia Atlas <akatlas@gmail.com> wrote:

In d= raft-ietf-i2rs-architecture-00 Sec 5.4.4:

" Many network elements have s= eparate policy and QoS mechanisms,
=
   including knobs which affect l=
ocal path computation and queue control
   capabilities.  These capabilities vary widely across implementations,
   and I2RS cannot model the full range of information collection or
   manipulation of these attributes.  A core set does need to be
   included in the I2RS data models and in the expected interfaces
   between the I2RS Agent and the network element, in order to provide
   basic capabilities and the hooks for future extensibility.
   [[Editor's note: This requires more discussion in the working
   group.]]"

I would like to start t=
hat discussion now.  
=
Personally, I have not seen or h=
eard much discussion or any information-models
around these templates.  What do people think is n=
ecessary?  How should this
part of the architecture draft change?
=

Thanks,
=
Alia (WG-Chair hat off)




____________________= ___________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman= /listinfo/i2rs
= --Apple-Mail-409E7E3F-FC54-46F2-B7A5-2AAE0A3593A3-- From russw@riw.us Fri Sep 13 07:56:57 2013 Return-Path: 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 67C3021F9E96 for ; Fri, 13 Sep 2013 07:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 3dNkBOVTiIzE for ; Fri, 13 Sep 2013 07:56:51 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id CD53511E8200 for ; Fri, 13 Sep 2013 07:56:47 -0700 (PDT) Received: from [156.39.10.22] (helo=[10.45.191.120]) by da31.namelessnet.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1VKUnZ-00053C-Fd; Fri, 13 Sep 2013 07:56:46 -0700 References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-EAE7CE84-E92D-4DD2-A670-8E056DCC6FE3 Content-Transfer-Encoding: 7bit Message-Id: <8CF77B95-7AE7-49DA-8692-F9E2761EF4F4@riw.us> X-Mailer: iPad Mail (10B329) From: Russ White Date: Fri, 13 Sep 2013 07:56:41 -0700 To: Alia Atlas X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Architecture Discussion 3: Operations are Immediate and continuing X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 14:56:57 -0000 --Apple-Mail-EAE7CE84-E92D-4DD2-A670-8E056DCC6FE3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > Personally, I have heard that this is a good simplification. Removing the= =20 > ability to specify the start-time and end-time of an operation adds comple= xity > and we don't clearly have use-cases that need it. Does anyone have a diff= erent > perspective? I think the simplifying assumption here is that the controller should hold t= he time state, not the agent. In other words, rather than telling the agent t= o start action x at time y, the controller should just wait until time y, an= d then send "start action x."=20 The agent should designed with the minimal amount of state and complexity, t= o get adoption rates up, etc. :-) Russ <>< russw@riw.us ?@?.com (engineer without a portfolio)= --Apple-Mail-EAE7CE84-E92D-4DD2-A670-8E056DCC6FE3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable 

Personally, I have heard that this is a good simplification.  Removin=
g the 
ability to specify t=
he start-time and end-time of an operation adds complexity
and we don't clearly have use-cases that need it. =
 Does anyone have a different
pe=
rspective?

I think the simplif= ying assumption here is that the controller should hold the time state, not t= he agent. In other words, rather than telling the agent to start action x at= time y, the controller should just wait until time y, and then send "start a= ction x." 

The agent should designed with the m= inimal amount of state and complexity, to get adoption rates up, etc.
<= div>
:-)

Russ


<>= ;<
?= @?.com (engineer without a portfolio)
= --Apple-Mail-EAE7CE84-E92D-4DD2-A670-8E056DCC6FE3-- From akatlas@gmail.com Fri Sep 13 07:57:12 2013 Return-Path: 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 2DDDB21E80A7 for ; Fri, 13 Sep 2013 07:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 pMMvK8tPjpGf for ; Fri, 13 Sep 2013 07:57:10 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id B830911E8180 for ; Fri, 13 Sep 2013 07:57:10 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id x13so2817128ief.1 for ; Fri, 13 Sep 2013 07:57:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/I/iEwQ1qe+SgpgNRId3TTKt1hPLOxWAcASylvv+ECM=; b=KZ+lOErqbIdZKQ4QYqXWpShwKOooZBc5HyEjUOhftjvKfAR8sAhAk6kINTBjgPZaqc hVRJksBs2KNnw0nreRMcGpVB6NPxwz4O97hTCZ4QmnqkUeHSJ0LC/ie0RM6QBmvcVoWf md6o7VJPq4XxrbMvtrx5oBJUFpCgCjTaqd7NcHeOa3b/5NgzqNdKRnT9QYFSbTa/tmdy 13ESPGNiVhxL7TYUqQaK2k8x1bka/AY5eTCkOZQELQu4rLeGarvpotS8wM70j5txSWhx e8Cq7C3FtAiO8JMSypumwBZJfXlZ7tposuFBkrhc5N0HDYPP/FC4mlkcAEwaA3JjNIPO 76Gg== MIME-Version: 1.0 X-Received: by 10.50.30.42 with SMTP id p10mr1467889igh.5.1379084228775; Fri, 13 Sep 2013 07:57:08 -0700 (PDT) Received: by 10.64.13.145 with HTTP; Fri, 13 Sep 2013 07:57:08 -0700 (PDT) In-Reply-To: <52329B75.2080703@cisco.com> References: <5231D77A.9050807@cisco.com> <5231DC28.9060600@cisco.com> <5231E14E.5020605@cisco.com> <5231FAD2.1060207@cisco.com> <52329B75.2080703@cisco.com> Date: Fri, 13 Sep 2013 10:57:08 -0400 Message-ID: From: Alia Atlas To: Joe Marcus Clarke Content-Type: multipart/alternative; boundary=047d7bdc9db2925cf804e6451145 Cc: "i2rs@ietf.org" 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 14:57:12 -0000 --047d7bdc9db2925cf804e6451145 Content-Type: text/plain; charset=ISO-8859-1 Hi Joe, Summarizing up top (but leaving context) For a graceful Agent restart (i.e. not a crash), I think the behavior can be implementation-dependent. The implementation can either notify all Clients that have data written that the state is being preempted/torn down or it can just notify all Clients (that it knows of) that the Agent is going down. These are important notifications to capture in the I2RS Agent Info-Model. I don't think that either needs to be explicitly required as the only mode. I am certainly willing to be convinced otherwise. For the case of an Agent crashing, I'm quite reluctant to create a heartbeat or persistent connection. This is a lot of complexity to add for what should be a quite rare case. If the Agent crashes, leave the state and the Client will get an error when it tries to connect or otherwise request something. This does argue that on connection, the Client should get an indication of something like an Agent boot count /session id (and boot time). Russ's idea of storing known clients for the agent to connect to on reboot makes sense to me. I really dislike the idea of adding significant complexity to handle an edge failure case. Alia On Fri, Sep 13, 2013 at 12:58 AM, Joe Marcus Clarke wrote: > On 9/12/13 3:49 PM, Alia Atlas wrote: > > [Alia] But we (the WG) said that it was an error because we expect > > coordination > > between the applications to avoid multiple writers of the same data. > > It's not an > > error because the Agent says so - the Agent would just report back what > > happened > > (successful write or fail due to higher priority). > > My point was that the Agent knows the priority. This isn't passed to > the RS. > > > [Alia] As Joel had said, I think we're trying to avoid the need for > > persistent > > connections just to confirm liveness. It's a heavy-handed way to do it. > > That said, > > we could use a mechanism to determine if the RS is up and if the > associated > > Agent is up. Of course, there can be multiple Agents per RS - each > > supporting > > different services or such. For a router reboot, a Client that is > > learning topology > > would hear very quickly that a router has failed or appeared. > > > > [Alia] So - developing a liveness detection mechanism is useful. But > > what would > > be useful is the ability for the RS to notify interested clients on a > > failure. Otherwise, > > what frequency would suffice for checking - when traffic can be being > > actively dropped > > or misrouted if the Agent has failed. Also - are we designing for the > > error-case of > > a crashed Agent rather than the normal case of a gracefully shut down > Agent? > > I was raising the point of both. In the graceful case, the Agent clears > all state and notifies all Clients. But the crash is a possibility, and > we should stipulate what should happen to state. > > I don't think we want the RS doing anything to the Clients directly. I > think perhaps an Agent->Client heartbeat is a useful thing if the Client > asks to be notified about changes. > > > > > A third model I thought of was a broker model in which the Agent > > rebooting would be a broadcast event to all subscribers. > > > > > > [Alia] I've been assuming, I guess, that Clients would hear about router > > failures via > > the topology DM based from the IGP. > > Router failure of Agent failure? > > > > > > > In either case, I saw that the Client would have some means of > knowing > > the Agent went away. > > > > > > [Alia] I can see that if the Client knew that the Agent went away > > (ungracefully), that > > having the associated RS clean up state would be fine. I haven't yet > > heard a fully baked > > design where the client would know rapidly. We (you?) could come up > > with one, but > > that needs to be written down and agreed to. Without that, I hear that > > the Client's state > > might suddenly disappear without the Client being able to tell - and am > > much more comfortable > > leaving it there to be removed either via CLI or to be read and then > > written again by the Client > > when it reconnects. > > I've been kicking around the idea of a pub-sub "heartbeat." This would > give the Client awareness of the Agent's "thereness." If the heartbeat > carried a boot count, the Client might not need for multiple dropped > heartbeats before reapplying state. I don't know if this is an ideal > way to confirm liveness of the agent, though I'm happy to propose it > more formally. I think the exact approach would depend on what the > pub-sub mechanism is determined to be. > > > One other thing I haven't raised is the operator impact. How else > could > > an operator (i.e., owner/admin of a device) flush the I2RS changes? > > There might be a malicious change or just some bad state, and they > want > > to clear that up. A restart of the Agent could do it without > reloading > > the device. > > > > > > [Alia] Why wouldn't using the CLI to flush the I2RS changes work? > > It would. I didn't realize you were okay with a graceful restart of the > Agent purging all RS state for which it is responsible. If you are, > then that is handled. > > > Also, that > > is a graceful restart of the Agent - where the Agent can tell each > > Client that all > > its written data has been preempted because the Agent is rebooting. I'm > > also > > concerned that the behavior make sense for if/when the Agent fails. I > > could be > > persuaded not to worry about that (Agents shouldn't crash) - but I'd > > prefer not to > > mandate complexity for that case. > > I think we should. Because if there is a crash from the Agent, how then > can an admin purge state? There would no longer be a clean way to do > this. I'm trying to think what an operator might like here. > > 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 > > > ---------------------------------------------------------------------------- > --047d7bdc9db2925cf804e6451145 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Joe,

Summarizing up top (but leaving= context)

For a graceful Agent restart (i.e. not a= crash), I think the behavior can be implementation-dependent. =A0The imple= mentation can either notify all Clients that have data written that the sta= te is being preempted/torn down or it can just notify all Clients (that it = knows of) that the Agent is going down. =A0These are important notification= s to capture in the I2RS Agent Info-Model. =A0I don't think that either= needs to be explicitly required as the only mode. =A0I am certainly willin= g to be convinced otherwise.

For the case of an Agent crashing, I'm quite reluct= ant to create a heartbeat or persistent connection. =A0 This is a lot of co= mplexity to add for what should be a quite rare case. =A0If the Agent crash= es, leave the state and the Client will get an error when it tries to conne= ct or otherwise request something. =A0This does argue that on connection, t= he Client should get an indication of something like an Agent boot count /s= ession id (and boot time). =A0 Russ's idea of storing known clients for= the agent to connect to on reboot makes sense to me.

I really dislike the idea of adding significant complex= ity to handle an edge failure case.

Alia


On Fri, Sep= 13, 2013 at 12:58 AM, Joe Marcus Clarke <jclarke@cisco.com>= wrote:
On 9/12/13 3:49 PM, Alia A= tlas wrote:
> [Alia] But we (the WG) said that it was an error because we expect
> coordination
> between the applications to avoid multiple writers of the same data. > =A0It's not an
> error because the Agent says so - the Agent would just report back wha= t
> happened
> (successful write or fail due to higher priority).

My point was that the Agent knows the priority. =A0This isn't pas= sed to
the RS.

> [Alia] As Joel had said, I think we're trying to avoid the need fo= r
> persistent
> connections just to confirm liveness. =A0It's a heavy-handed way t= o do it.
> =A0That said,
> we could use a mechanism to determine if the RS is up and if the assoc= iated
> Agent is up. =A0Of course, there can be multiple Agents per RS - each<= br> > supporting
> different services or such. For a router reboot, a Client that is
> learning topology
> would hear very quickly that a router has failed or appeared.
>
> [Alia] So - developing a liveness detection mechanism is useful. =A0Bu= t
> what would
> be useful is the ability for the RS to notify interested clients on a<= br> > failure. =A0Otherwise,
> what frequency would suffice for checking - when traffic can be being<= br> > actively dropped
> or misrouted if the Agent has failed. =A0 =A0Also - are we designing f= or the
> error-case of
> a crashed Agent rather than the normal case of a gracefully shut down = Agent?

I was raising the point of both. =A0In the graceful case, the Agent c= lears
all state and notifies all Clients. =A0But the crash is a possibility, and<= br> we should stipulate what should happen to state.

I don't think we want the RS doing anything to the Clients directly. = =A0I
think perhaps an Agent->Client heartbeat is a useful thing if the Client=
asks to be notified about changes.

>
> =A0 =A0 A third model I thought of was a broker model in which the Age= nt
> =A0 =A0 rebooting would be a broadcast event to all subscribers.
>
>
> [Alia] I've been assuming, I guess, that Clients would hear about = router
> failures via
> the topology DM based from the IGP.

Router failure of Agent failure?

>
>
> =A0 =A0 In either case, I saw that the Client would have some means of= knowing
> =A0 =A0 the Agent went away.
>
>
> [Alia] I can see that if the Client knew that the Agent went away
> (ungracefully), that
> having the associated RS clean up state would be fine. =A0I haven'= t yet
> heard a fully baked
> design where the client would know rapidly. =A0We (you?) could come up=
> with one, but
> that needs to be written down and agreed to. =A0Without that, I hear t= hat
> the Client's state
> might suddenly disappear without the Client being able to tell - and a= m
> much more comfortable
> leaving it there to be removed either via CLI or to be read and then > written again by the Client
> when it reconnects.

I've been kicking around the idea of a pub-sub "heartbeat.&q= uot; =A0This would
give the Client awareness of the Agent's "thereness." =A0If t= he heartbeat
carried a boot count, the Client might not need for multiple dropped
heartbeats before reapplying state. =A0I don't know if this is an ideal=
way to confirm liveness of the agent, though I'm happy to propose it more formally. =A0I think the exact approach would depend on what the
pub-sub mechanism is determined to be.

> =A0 =A0 One other thing I haven't raised is the operator impact. = =A0How else could
> =A0 =A0 an operator (i.e., owner/admin of a device) flush the I2RS cha= nges?
> =A0 =A0 There might be a malicious change or just some bad state, and = they want
> =A0 =A0 to clear that up. =A0A restart of the Agent could do it withou= t reloading
> =A0 =A0 the device.
>
>
> [Alia] =A0Why wouldn't using the CLI to flush the I2RS changes wor= k?

It would. =A0I didn't realize you were okay with a graceful resta= rt of the
Agent purging all RS state for which it is responsible. =A0If you are,
then that is handled.

> =A0Also, that
> is a graceful restart of the Agent - where the Agent can tell each
> Client that all
> its written data has been preempted because the Agent is rebooting. = =A0I'm
> also
> concerned that the behavior make sense for if/when the Agent fails. = =A0I
> could be
> persuaded not to worry about that (Agents shouldn't crash) - but I= 'd
> prefer not to
> mandate complexity for that case.

I think we should. =A0Because if there is a crash from the Agent, how= then
can an admin purge state? =A0There would no longer be a clean way to do
this. =A0I'm trying to think what an operator might like here.

Joe

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

---------------------------------------------------------------------------= -

--047d7bdc9db2925cf804e6451145-- From akatlas@gmail.com Fri Sep 13 08:14:10 2013 Return-Path: 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 6C5FD11E8209 for ; Fri, 13 Sep 2013 08:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 405LTgnQZgj1 for ; Fri, 13 Sep 2013 08:14:09 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 850EC11E8200 for ; Fri, 13 Sep 2013 08:13:56 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id u16so2718754iet.5 for ; Fri, 13 Sep 2013 08:13:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SKv0c27KvvKswS6glzp7xc8xyKvoVDT/pxE7MhVWiGU=; b=Ns7p5zBEnVNy24zweO8k2RhjFEZ8c4szC5g2uzXGHtTLGIPanvzMGqsOabJO++vOs9 Ov5dF4RbuevQu7KkXlWJdkEb8+LNmLX6W8t5qRw/UHjuy+L0l/uOSil4I/htXUX53n0V sFHPUCTC2YIYkbq0rY+UsqEkJwyvGHmP4P2trSzVizPSARnTwsJlQHz7c4WknnGQ7IMs UUn5NPQvjDPHbxCOIqpouuYBMdq29cdooQhGEZuU4JEjAJtJzwpTTdLamBCZz1owhg1I wRQSVIBxH3NiF3y7dhJW8Wj0Bgp3o5FyPetw3Wl1AgCmi7UL80I2qSVJJZWR4Q7nKyPj Rlmw== MIME-Version: 1.0 X-Received: by 10.50.30.42 with SMTP id p10mr1500744igh.5.1379085236117; Fri, 13 Sep 2013 08:13:56 -0700 (PDT) Received: by 10.64.13.145 with HTTP; Fri, 13 Sep 2013 08:13:56 -0700 (PDT) In-Reply-To: References: Date: Fri, 13 Sep 2013 11:13:56 -0400 Message-ID: From: Alia Atlas To: Sriganesh Kini Content-Type: multipart/alternative; boundary=047d7bdc9db29d2c3904e6454d31 Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Architecture Discussion 4: templates for Policy and QoS mechanisms X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 15:14:10 -0000 --047d7bdc9db29d2c3904e6454d31 Content-Type: text/plain; charset=ISO-8859-1 Sri, I'm delighted to hear that some thought and progress is going on in this area. I agree that we'll want to have some templates (named objects) available. I don't see trying to standardize all of these mechanisms - though a core set of types (policing, rate-limiting, queuing, etc) certainly make sense. I can see having a template with a type and name - and the application has to understand what it was set up for. One could add to that by specifying a data-model that is used for that template... Possibly we can agree on some basic parameters that are generally supported or accepted as modeling common behavior - and that can be pointed to (or to a proprietary data-model that is more specific). Alia On Fri, Sep 13, 2013 at 12:41 AM, Sriganesh Kini < sriganesh.kini@ericsson.com> wrote: > Hi Alia, > > As part of of evolving the RIB IM the authors are looking into > routing-policies and policy-based-routing (PBR) IMs. As part of the PBR IMs > we are discussing whether the QoS IMs (policing, rate-limiting, queueing > ... etc) should be in scope and what they should include. As you quoted > from the arch doc, these could vary widely across implementations and we > are discussing what the core set may be. We have not finalized this yet and > it is possible that the QoS IM would be in a separate draft. > > Also, as part of discussing routing-policies we have considered making > templates (named objects) that can be re-used (e.g. across various RIBs). > These objects should be at the top-level of the IMs. It would be useful to > do this in a manner that is consistent across various IMs. > > Thanks > - Sri > > > On Thu, Sep 12, 2013 at 7:55 AM, Alia Atlas wrote: > >> In draft-ietf-i2rs-architecture-00 Sec 5.4.4: >> >> " Many network elements have separate policy and QoS mechanisms, >> >> including knobs which affect local path computation and queue control >> capabilities. These capabilities vary widely across implementations, >> and I2RS cannot model the full range of information collection or >> manipulation of these attributes. A core set does need to be >> included in the I2RS data models and in the expected interfaces >> between the I2RS Agent and the network element, in order to provide >> basic capabilities and the hooks for future extensibility. >> [[Editor's note: This requires more discussion in the working >> group.]]" >> >> >> I would like to start that discussion now. >> >> >> Personally, I have not seen or heard much discussion or any information-models >> >> around these templates. What do people think is necessary? How should this >> >> part of the architecture draft change? >> >> >> Thanks, >> >> Alia (WG-Chair hat off) >> >> >> >> >> >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> >> > --047d7bdc9db29d2c3904e6454d31 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Sri,

I'm delighted to hear that som= e thought and progress is going on in this area.
I agree that we&= #39;ll want to have some templates (named objects) available. =A0I don'= t see
trying to standardize all of these mechanisms - though a core set of t= ypes (policing, rate-limiting, queuing, etc) certainly make sense.

I can see having a template with a type and name - and the= application has to understand what it was set up for. =A0One could add to = that by specifying a data-model that is used for that template... =A0Possib= ly we can agree on some basic parameters that are generally supported or ac= cepted as modeling common behavior - and that can be pointed to (or to a pr= oprietary data-model that is more specific).

Alia


On Fri, Sep 13, 2013 at 12:41 AM, Sriganesh Kini <sriganesh.kini@ericsson.com> wrote:
Hi Alia,

<= /div>As part of of evolving the RIB IM the authors are looking into routing= -policies and policy-based-routing (PBR) IMs. As part of the PBR IMs we are= discussing whether the QoS IMs (policing, rate-limiting, queueing ... etc)= should be in scope and what they should include. As you quoted from the ar= ch doc, these could vary widely across implementations and we are discussin= g what the core set may be. We have not finalized this yet and it is possib= le that the QoS IM would be in a separate draft.

Also, as part of discussing routing-policies we have conside= red making templates (named objects) that can be re-used (e.g. across vario= us RIBs). These objects should be at the top-level of the IMs. It would be = useful to do this in a manner that is consistent across various IMs.

Thanks
- Sri


On Thu, Sep 12, 2013 at 7:55 AM, Alia Atlas <akatlas@gmail.com><= /span> wrote:
In draft-ietf-i2rs-arc= hitecture-00 Sec 5.4.4:

" = Many network elements have separate policy and QoS mechanisms,
   including knobs which affect local path computation and=
 queue control
   capabilities.  These capabilities vary widely across implementations,
   and I2RS cannot model the full range of information collection or
   manipulation of these attributes.  A core set does need to be
   included in the I2RS data models and in the expected interfaces
   between the I2RS Agent and the network element, in order to provide
   basic capabilities and the hooks for future extensibility.
   [[Editor's note: This requires more discussion in the working
   group.]]"

I would like to start that discussion now.  

Personally, I have not seen or heard much discussion or an=
y information-models

around these templates.  What d=
o people think is necessary?  How should this
=
part of the architecture draft change?

Thanks,
Alia (WG-Chair hat off)

<=
/font>

_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs



--047d7bdc9db29d2c3904e6454d31-- From akatlas@gmail.com Fri Sep 13 08:16:07 2013 Return-Path: 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 A813121E80DC for ; Fri, 13 Sep 2013 08:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 a3o7ThcFyqdM for ; Fri, 13 Sep 2013 08:16:07 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 4987321F9967 for ; Fri, 13 Sep 2013 08:16:02 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id e14so2662808iej.24 for ; Fri, 13 Sep 2013 08:16:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QpMAT34sY471hW6nq4Ez4WJuKKNXyoeT3E/C2ZAsUmg=; b=Qf0AyCfxww58oqOyCdVVKypW74SahTsgDY3ZzymogdAo55zDNsL/53GCxWCAgeE997 EsOJhnlV1BQwbVYlCIMnvqG6gbGju5zUtUiVsCT28jw9yp9HxzqXBRfkrkM6tgPkcwOt wHu+HtDqZnmY1IQkNTYjQIcCm5qWR+ROiAQGMwz6+FGrXwnsiRMP2T12PZuJ7epMjwwm q+nbkmq9Rtcdjwv9xCuU28GUkWK8fKUvf/nHlzlSAK2mrw2LONpQe07B4IvxCbXIDBIY hj6k439vu5ou2IAzDkD9WCZ+j3uF3bgwdW0GfjC3rDEdg8kzJY5Vt0hYA37U9xiuMLQJ B3Vw== MIME-Version: 1.0 X-Received: by 10.50.128.137 with SMTP id no9mr1549011igb.36.1379085361914; Fri, 13 Sep 2013 08:16:01 -0700 (PDT) Received: by 10.64.13.145 with HTTP; Fri, 13 Sep 2013 08:16:01 -0700 (PDT) In-Reply-To: <8CF77B95-7AE7-49DA-8692-F9E2761EF4F4@riw.us> References: <8CF77B95-7AE7-49DA-8692-F9E2761EF4F4@riw.us> Date: Fri, 13 Sep 2013 11:16:01 -0400 Message-ID: From: Alia Atlas To: Russ White Content-Type: multipart/alternative; boundary=047d7b10cf0d1cad1804e64555a8 Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Architecture Discussion 3: Operations are Immediate and continuing X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 15:16:07 -0000 --047d7b10cf0d1cad1804e64555a8 Content-Type: text/plain; charset=ISO-8859-1 Oh, I totally agree as far as trying to have a minimal amount of state and complexity. My concern has been making the network from the client to the agent mission critical, but that's clearly documented in the architecture. I just want to confirm the consensus so we can honestly remove the Editor's note and go forward. Alia On Fri, Sep 13, 2013 at 10:56 AM, Russ White wrote: > > Personally, I have heard that this is a good simplification. Removing the > > ability to specify the start-time and end-time of an operation adds complexity > > and we don't clearly have use-cases that need it. Does anyone have a different > > perspective? > > > I think the simplifying assumption here is that the controller should hold > the time state, not the agent. In other words, rather than telling the > agent to start action x at time y, the controller should just wait until > time y, and then send "start action x." > > The agent should designed with the minimal amount of state and complexity, > to get adoption rates up, etc. > > :-) > > Russ > > > <>< > russw@riw.us > ?@?.com (engineer without a portfolio) > --047d7b10cf0d1cad1804e64555a8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Oh, I totally agree as far as trying to have a minimal amo= unt of state and complexity.
My concern has been making the network fro= m the client to the agent mission critical,
but that's clearl= y documented in the architecture. =A0I just want to confirm the consensus s= o
we can honestly remove the Editor's note and go forward.

Alia


On Fri, Sep 13, 2013 at 10:56 AM, Russ White <russw@riw.us= > wrote:
Personally, I have heard that t=
his is a good simplification.  Removing the=A0
ability to specify the start-time and end-time of an operation adds comple=
xity
and we don't clearly have use-cases that need it.  Doe=
s anyone have a different
perspective?
=

I think the simplifying assumption here i= s that the controller should hold the time state, not the agent. In other w= ords, rather than telling the agent to start action x at time y, the contro= ller should just wait until time y, and then send "start action x.&quo= t;=A0

The agent should designed with the minimal amount of st= ate and complexity, to get adoption rates up, etc.

:-)

Russ


<><
?@?.com (engineer without a portfolio)

--047d7b10cf0d1cad1804e64555a8-- From sriganeshkini@gmail.com Fri Sep 13 09:59:31 2013 Return-Path: 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 4744F11E816D for ; Fri, 13 Sep 2013 09:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 bjEyn423N4Ze for ; Fri, 13 Sep 2013 09:59:29 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 7154D11E80FC for ; Fri, 13 Sep 2013 09:59:29 -0700 (PDT) Received: by mail-pa0-f49.google.com with SMTP id ld10so2755487pab.36 for ; Fri, 13 Sep 2013 09:59:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=j5hH//UCVF/byOoPVuRjD6yhUWOMP5IGmwTZdXkZTVs=; b=XZCtmAciRH9FpxIe2q/B+JEEIGQEaLHLXtBoLz8O7gd2h6tmk4maR/cgiFdowB37pp 8I2n1y4bAH6qTNidIxnr+yJ6x+zUAzKIcqUXsGz9uhwH0joU9aiJtD5tv5dxJXIxEV7q ugo7eNqYHOOgJ5fk86I1dl1Zqmv08LlX9RF+N0J4cu8xDVwNxpRVWfkSDcXOnL9rVj4v AuWdYZzjSts2mivQTrtBS+tKvZCsSn24g5j22ZBuJtBr5BAw00Dj3bkd01TA+DXIb9ax mh3dyXQTHv8vxiOmmCACvMqCgmS/Q6A97eQ//wC0/jR3nHFHnuXP/OGuqZ4gI3z9qg6l utCA== X-Received: by 10.68.236.168 with SMTP id uv8mr14658104pbc.124.1379091565570; Fri, 13 Sep 2013 09:59:25 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.70.13.129 with HTTP; Fri, 13 Sep 2013 09:58:55 -0700 (PDT) In-Reply-To: <42DC10E7-3A2A-4BCF-BD61-7C38134B7E37@riw.us> References: <42DC10E7-3A2A-4BCF-BD61-7C38134B7E37@riw.us> From: Sriganesh Kini Date: Fri, 13 Sep 2013 09:58:55 -0700 X-Google-Sender-Auth: 2ZG_ptudq1nZknV41su-MWEkoXY Message-ID: To: Russ White Content-Type: multipart/alternative; boundary=047d7b33d882e0f63004e646c6a4 Cc: "i2rs@ietf.org" , Alia Atlas Subject: Re: [i2rs] Architecture Discussion 4: templates for Policy and QoS mechanisms X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 16:59:31 -0000 --047d7b33d882e0f63004e646c6a4 Content-Type: text/plain; charset=UTF-8 Russ, Characterizing every possible QoS model is practically impossible. Do you have any standard model in mind that would be suitable to use as a base ? I would also be interested in hearing feedback on PBR. The 5 tuple based classification seems to be the most basic. But additionally one could use other fields ethernet, MPLS, QoS bits, length, range etc to construct the classification policy. Similar issues for for rewriting packet header fields. If anyone has any specific model they would like to see please send feedback to the list (or the draft authors) with the supporting use-case. Thanks - Sri On Fri, Sep 13, 2013 at 7:50 AM, Russ White wrote: > > I'm a little worried about trying to characterize every possible QoS model > out there... Seems like we should just stick to some standard model, and > let implementors map between that and the reality. > > :-) > > Russ > > <>< > russw@riw.us > ?@?.com (engineer without a portfolio) > > On Sep 12, 2013, at 7:55 AM, Alia Atlas wrote: > > In draft-ietf-i2rs-architecture-00 Sec 5.4.4: > > " Many network elements have separate policy and QoS mechanisms, > > including knobs which affect local path computation and queue control > capabilities. These capabilities vary widely across implementations, > and I2RS cannot model the full range of information collection or > manipulation of these attributes. A core set does need to be > included in the I2RS data models and in the expected interfaces > between the I2RS Agent and the network element, in order to provide > basic capabilities and the hooks for future extensibility. > [[Editor's note: This requires more discussion in the working > group.]]" > > > I would like to start that discussion now. > > > Personally, I have not seen or heard much discussion or any information-models > > around these templates. What do people think is necessary? How should this > > part of the architecture draft change? > > > Thanks, > > Alia (WG-Chair hat off) > > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > --047d7b33d882e0f63004e646c6a4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Russ,

Characterizing every possible QoS= model is practically impossible. Do you have any standard model in mind th= at would be suitable to use as a base ?

I would al= so be interested in hearing feedback on PBR. The 5 tuple based classificati= on seems to be the most basic. But additionally one could use other fields = ethernet, MPLS, QoS bits, length, range etc to construct the classification= policy. Similar issues for for rewriting packet header fields. If anyone h= as any specific model they would like to see please send feedback to the li= st (or the draft authors) with the supporting use-case.

Thanks
- Sri



On Fri, Sep 13, 201= 3 at 7:50 AM, Russ White <russw@riw.us> wrote:

I'= m a little worried about trying to characterize every possible QoS model ou= t there... Seems like we should just stick to some standard model, and let = implementors map between that and the reality.

:-)

Russ

<>&= lt;
?@?.com (engineer without a portfolio)

On Sep 12, 2013, at 7:55 AM, Alia Atlas <akatlas@gmail.com> wrote:

In draft-ietf-i2rs-architecture-00 Sec 5.4.4:
" Many network elemen= ts have separate policy and QoS mechanisms,
   including knobs which affect local path computation and=
 queue control
   capabilities.  These capabilities vary widely across implementations,
   and I2RS cannot model the full range of information collection or
   manipulation of these attributes.  A core set does need to be
   included in the I2RS data models and in the expected interfaces
   between the I2RS Agent and the network element, in order to provide
   basic capabilities and the hooks for future extensibility.
   [[Editor's note: This requires more discussion in the working
   group.]]"

I would like to start that discussion now.  

Personally, I have not seen or heard much discussion or an=
y information-models

around these templates.  What d=
o people think is necessary?  How should this
=
part of the architecture draft change?

Thanks,
Alia (WG-Chair hat off)

<=
/font>
=
_______________________________________________
= i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs


--047d7b33d882e0f63004e646c6a4-- From jclarke@cisco.com Fri Sep 13 10:57:35 2013 Return-Path: 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 0C5A311E8166 for ; Fri, 13 Sep 2013 10:57:35 -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 phGPOaLy-j75 for ; Fri, 13 Sep 2013 10:57:30 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7B821F9FCF for ; Fri, 13 Sep 2013 10:57:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2129; q=dns/txt; s=iport; t=1379095034; x=1380304634; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=YDjYx+6fz9DEeadJFV0tx0qRPiinznbM3eQVjVj1yrg=; b=MEvsR4ZIieEfu+rCIY/TBQaOrpARNVTT8G3JxLy16E4V8O7FVwNrynzC prH1js4uP0U4JivoClVKf2c3bQqsZkN2+CykJY6PwZy5vX38jzF5QAyCs cWNLxvnwvOCzN9OwVzf8xQdA6jE/quavF1Jho5kplsISLROxYa8MoZ2Om c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAM5QM1KtJV2a/2dsb2JhbABYA4MHOMFHgRwWdIIlAQEBAwEBAQFrCw4CCxIGCSUPAgoMIg4GDQEFAgEBh3kGDLlBBASOJIE5EAcRhA0Dl3qRdINAIIE1 X-IronPort-AV: E=Sophos;i="4.90,899,1371081600"; d="scan'208";a="259450077" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 13 Sep 2013 17:57:11 +0000 Received: from dhcp-10-150-54-134.cisco.com (dhcp-10-150-54-134.cisco.com [10.150.54.134]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r8DHvB1U025847; Fri, 13 Sep 2013 17:57:11 GMT Message-ID: <523351F7.10006@cisco.com> Date: Fri, 13 Sep 2013 13:57:11 -0400 From: Joe Marcus Clarke 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: Russ White References: <5231D77A.9050807@cisco.com> <5231DC28.9060600@cisco.com> <5231E14E.5020605@cisco.com> <5231FAD2.1060207@cisco.com> <52329B75.2080703@cisco.com> <006EB573-5BA1-4DA3-8EB6-6E8DD98AE48A@riw.us> In-Reply-To: <006EB573-5BA1-4DA3-8EB6-6E8DD98AE48A@riw.us> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "i2rs@ietf.org" , Alia Atlas 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 17:57:35 -0000 On 9/13/13 10:47 AM, Russ White wrote: > >> I think we should. Because if there is a crash from the Agent, how then >> can an admin purge state? There would no longer be a clean way to do >> this. I'm trying to think what an operator might like here. > > IMHO: > > - no heartbeat or any other persistent connection > - if the controller crashes, on startup up it should connect to all the clients it knows about (some controller state needs to be persistent across reboot) and send at least one null or other command > - each packet/command the controller sends contains a "boot count," or "session I'd," or something like that; this must increment each time the controller reboots or resets its state > - if a client receives a command/packet with the "wrong" session I'd (or whatever it's called) it clears any state associated with that controller This approach is fine with me, too. I just didn't know if a heartbeat would be less desirable than having the Agent maintain a list of interested Clients. And for terminology sake, I think you mean Agent not "controller?" The controller would be more like the Client. Joe > > This doesn't require the agent to keep persistent state, but allows current state to remain without persistent communication. It's possible to design a graceful restart mechanism (like bgp), but lets leave it out of the discussion until we get a better handle on what the protocols and models actually look like. We can speculate, but the devil is in the details in graceful restart. > > :-) > > Russ > > > > <>< > russw@riw.us > ?@?.com (engineer without a portfolio) > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > -- 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 ---------------------------------------------------------------------------- From shares@ndzh.com Fri Sep 13 11:34:59 2013 Return-Path: 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 6BDBF11E80FF for ; Fri, 13 Sep 2013 11:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.725 X-Spam-Level: X-Spam-Status: No, score=-0.725 tagged_above=-999 required=5 tests=[AWL=0.874, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1] 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 xnI+eSFUNxEB for ; Fri, 13 Sep 2013 11:34:55 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 34D2811E80FC for ; Fri, 13 Sep 2013 11:34:55 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.228.15; From: "Susan Hares" To: "'Joel M. Halpern'" , References: <523302BF.4040701@joelhalpern.com> In-Reply-To: <523302BF.4040701@joelhalpern.com> Date: Fri, 13 Sep 2013 14:34:48 -0400 Message-ID: <020b01ceb0af$edc2e020$c948a060$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ3g2vs0OZu4MOg+vkSaOQOWtG+nJhyVH1w Content-Language: en-us X-Authenticated-User: skh@ndzh.com Subject: Re: [i2rs] RIB Model draft X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 18:34:59 -0000 Nitin: Like Joel, I support the adoption of the draft. It is a better starting place than the previous draft. I would like suggest you need to consider Joel's comments and Russ' comments. Here's a few things that can hit problems in the draft: 1) Why is the BGP route distinguisher specified on page 7? Why AS Path? This is BGP specific. A virtual private VPN ID - may be Ok, but linking it to the BGP identifier may bring problematic results. I ack Joel's comment below on the need to make it generic instead of protocol specific. 2) What happens if you want to change nexthop [10] for prefix 10.2.0/16 as part of the RIB change? Seems to be something you'd want to be able do., Can you? 3) I agree with Joel's comment below on load balancing. You either need to make it generic or include all variants of load balancing. 4) I agree with Joel your TTL specification to/from tunnel needs tightening. If you want to support it, I think it should be a "may" support not MUST. 5) Can you tie security values as an attribute to being able to set/clear FIB entries? Your note "reason - not authorized begs this question p. 16. Your protection list on p. 21 suggest there is a preference. Is the preference a value or is it a reference. 6) Some Forwarding Engines could allow your next-hop list to be an index id #. Can you provide an ID number for reference for your next hop lists? Editorial / Information 1) Would you look at the form and syntax that the netmod yang modules are using to specify information trees? If you think you are using the same structure, please tell me why. If you are not using the same structure, why not? 2) Is security a tree structure or a value? Your protection list seems to be a value. Is this meant to be a value or reference (p. 21) 3) Does netmod/yang models do a better job of nexhop list presentation? This is a good start. I hope will see more revisions soon. Sue -----Original Message----- From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Friday, September 13, 2013 8:19 AM To: i2rs@ietf.org Subject: [i2rs] RIB Model draft I support adoption of this draft. I do have some questions, brought to my attention when some of my folks read the draft. Given that metrics are not comparable between routing protocols, or even between distinct instances of routing protocols, why are the metrics in the general RIB model instead of the protocol specific models? Similarly, why is AS Path in this model, rather than in the BGP model? Whether the decision is implemented in BGP or a common RIB model would seem implementation specific, but from a model perspective it seems to be a BGP-specific property rather than a generic RIB property. The load balancing attributes seem to reflect a particular implementation strategy. While a not unreasonable strategy, the modeling seems pretty implementation specific. This applies to both the specifics of load balance weight and the interaction of that weight with protection preference. Having nodecrementTTL has a general nexthop attribute seems a mistake. In fact, having a next hop with no decrement seems very dangerous, since one could have a looping tunnel chain with no decrementing. Is this really something we want in the model? (I can't stop someone from doing it in an implementation.) While the model should permit handling the TTL propagation into and out of tunnels, it should not mandate support for specific modes. How do we indicate that support for things like the NO_PROPAGATE_TTL flag is optional, or conversely always set? Minor: I presume that the cardinality of 0 is allowed in the relationship between route and nexthop-list to reflect incomplete route entries? If so, shouldn't the text say so? Nit: figure 2 should include multicast. Yours, Joel _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From russw@riw.us Fri Sep 13 13:51:03 2013 Return-Path: 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 E647611E80D3 for ; Fri, 13 Sep 2013 13:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] 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 F-F8SheaF4RM for ; Fri, 13 Sep 2013 13:50:58 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id A1A2B11E80D5 for ; Fri, 13 Sep 2013 13:50:57 -0700 (PDT) Received: from ip-64-134-150-113.public.wayport.net ([64.134.150.113] helo=RussPC) by da31.namelessnet.net with esmtpa (Exim 4.80.1) (envelope-from ) id 1VKaKO-0004V5-L4; Fri, 13 Sep 2013 13:50:56 -0700 From: "Russ White" To: "'Joe Marcus Clarke'" References: <5231D77A.9050807@cisco.com> <5231DC28.9060600@cisco.com> <5231E14E.5020605@cisco.com> <5231FAD2.1060207@cisco.com> <52329B75.2080703@cisco.com> <006EB573-5BA1-4DA3-8EB6-6E8DD98AE48A@riw.us> <523351F7.10006@cisco.com> In-Reply-To: <523351F7.10006@cisco.com> Date: Fri, 13 Sep 2013 16:51:00 -0400 Message-ID: <01c401ceb0c2$f4c9e860$de5db920$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQFnU0vmcS1t1TbTG9e3Q7rMh2OUDQFEGLsuAZj+/hgCBFz8tQJ/6IiuAq9uJbUBXbWcWAIWTipWArLer2oA8fWMDAIHZIluAgnweo6Z6QWo0A== Content-Language: en-us X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Cc: i2rs@ietf.org, 'Alia Atlas' 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 20:51:04 -0000 > This approach is fine with me, too. I just didn't know if a heartbeat would be > less desirable than having the Agent maintain a list of interested Clients. Okay, I'm lost in the terminology again. :-) I think of the controller as being the off box device that's doing the injection, while the agent is the on box piece doing the actual manipulation of the devices routing information. So I'm thinking that the "controller" (or the "client?") would be one some sort of box that would be likely to have a spinning drive and the accompanying database constructs to keep the information required to persist over a reboot --while the "agent," residing on the router/forwarding device itself, would be more likely to be lightweight, etc. Further, the point seems, to me, to allow the router/forwarding device to reboot into a "clean state" represented by local configuration. To wit --if I've committed a command that causes the router/forwarding device to crash, I don't want that command to persist when it reboots, nor do I want it to be in some unknown state that might, or might not, include stuff put into policy from the "controller" over the time it's been operating. A clean slate to "locally stored config" seems like the safest bet all around (?). :-) Russ From jclarke@cisco.com Sat Sep 14 09:47:08 2013 Return-Path: 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 41B0121E81C0 for ; Sat, 14 Sep 2013 09:47:08 -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 JuFGVrYHHbZF for ; Sat, 14 Sep 2013 09:47:03 -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 0EE4521E81C1 for ; Sat, 14 Sep 2013 09:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2764; q=dns/txt; s=iport; t=1379177223; x=1380386823; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=iUhEU3VabFoJmcvz3+S7/91kuGqha+hnI6hzQnbMbxw=; b=gdjqJalnp4qlAUJKSmPQVNheUBg9eaCIIOrS2WAn4lDTejHxuSyAZJst SE/hTfLNrTktH7EbWyW7lBVt7/XRPuO+fcTWoOUFoZiq/fxlPT4s2Rdxo 5Uy8QgPo23gPmnF7qhA02FlMJT0+NxVL5bTcv3KPDQ2XpdmtUDbl2jTD5 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4FALORNFKtJV2d/2dsb2JhbABYA4MHsHqRC4EdFnSCJQEBAQMBeQ4CCxIGCSUPAgouDgYNAQUCAQGHeQa6AgSOJoE5EAcRhA0Dl3uRdINAIIE1 X-IronPort-AV: E=Sophos;i="4.90,904,1371081600"; d="scan'208";a="259847202" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 14 Sep 2013 16:47:01 +0000 Received: from rtp-jclarke-8919.cisco.com (rtp-jclarke-8919.cisco.com [10.117.46.170]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r8EGl1bX023814; Sat, 14 Sep 2013 16:47:01 GMT Message-ID: <52349306.305@cisco.com> Date: Sat, 14 Sep 2013 12:47:02 -0400 From: Joe Marcus Clarke 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: Russ White References: <5231D77A.9050807@cisco.com> <5231DC28.9060600@cisco.com> <5231E14E.5020605@cisco.com> <5231FAD2.1060207@cisco.com> <52329B75.2080703@cisco.com> <006EB573-5BA1-4DA3-8EB6-6E8DD98AE48A@riw.us> <523351F7.10006@cisco.com> <01c401ceb0c2$f4c9e860$de5db920$@riw.us> In-Reply-To: <01c401ceb0c2$f4c9e860$de5db920$@riw.us> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: i2rs@ietf.org, 'Alia Atlas' 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Sep 2013 16:47:08 -0000 On 9/13/13 4:51 PM, Russ White wrote: > >> This approach is fine with me, too. I just didn't know if a heartbeat > would be >> less desirable than having the Agent maintain a list of interested > Clients. > > Okay, I'm lost in the terminology again. :-) I think of the controller as > being the off box device that's doing the injection, while the agent is the > on box piece doing the actual manipulation of the devices routing > information. So I'm thinking that the "controller" (or the "client?") would > be one some sort of box that would be likely to have a spinning drive and > the accompanying database constructs to keep the information required to > persist over a reboot --while the "agent," residing on the router/forwarding > device itself, would be more likely to be lightweight, etc. Further, the > point seems, to me, to allow the router/forwarding device to reboot into a > "clean state" represented by local configuration. Yes, I'm with you. Controller == I2RS Client. The part of my email you quote seems in line with what you've written here. In your previous email you seemed to use client and controller to mean different things. At one point you said, "if the controller crashes, on startup up it should connect to all the clients it knows about (some controller state needs to be persistent across reboot) and send at least one null or other command" To me, I read this as: "if the _Agent_ crashes, on startup up it should connect to all the _Clients_ it knows about (some _Agent_ state needs to be persistent across reboot) and send at least one null or other command" Did I read that right? > > To wit --if I've committed a command that causes the router/forwarding > device to crash, I don't want that command to persist when it reboots, nor > do I want it to be in some unknown state that might, or might not, include > stuff put into policy from the "controller" over the time it's been > operating. A clean slate to "locally stored config" seems like the safest > bet all around (?). Agreed (I think everyone is in agreement on that), but in this case I look at the Agent as possibly being a separate isolated process from the router/forwarding device. So the Agent can crash independent of the forwarding device. I'm saying that if that happens, the state in the RS that was put there by the Agent should be removed. 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 ---------------------------------------------------------------------------- From jclarke@cisco.com Sat Sep 14 09:50:29 2013 Return-Path: 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 10A6621E81C9 for ; Sat, 14 Sep 2013 09:50:29 -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 6-dCwY008BIw for ; Sat, 14 Sep 2013 09:50:24 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id A59E821E81C4 for ; Sat, 14 Sep 2013 09:50:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8034; q=dns/txt; s=iport; t=1379177423; x=1380387023; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=giA/kIVw1l1KViM70f8/Jli6JcFvFUUGdo3Xrk012zA=; b=K1rq+RT8VL1mI14N/4hX+3fsDvEoKQVW5/5ZS22aG02d7H/Y5ZIt1foj 9LloVyi8SQBggV0GWImXBqjjtvqBAwX/rVDFOtWs6jnPJsjGAEDm5EMpo 87PitkB5wn+rZObyRNInRPP3nR7vsDCBkmaGkeZY+QHqaYPD6cowJHy/M 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4FAI+TNFKtJV2Y/2dsb2JhbABYA4MHwgWBHRZ0giUBAQEDASdABgsBDgILDgQGCRYIBwkDAgECAQkrAw4GDQEFAgEBh3kGugIEjiaBORAHEYQNA5d7kXSDQCCBNQ X-IronPort-AV: E=Sophos;i="4.90,904,1371081600"; d="scan'208";a="259752029" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 14 Sep 2013 16:50:22 +0000 Received: from rtp-jclarke-8919.cisco.com (rtp-jclarke-8919.cisco.com [10.117.46.170]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r8EGoJpU032130; Sat, 14 Sep 2013 16:50:20 GMT Message-ID: <523493CB.3000504@cisco.com> Date: Sat, 14 Sep 2013 12:50:19 -0400 From: Joe Marcus Clarke 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: Alia Atlas References: <5231D77A.9050807@cisco.com> <5231DC28.9060600@cisco.com> <5231E14E.5020605@cisco.com> <5231FAD2.1060207@cisco.com> <52329B75.2080703@cisco.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "i2rs@ietf.org" 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Sep 2013 16:50:29 -0000 On 9/13/13 10:57 AM, Alia Atlas wrote: > Hi Joe, > > Summarizing up top (but leaving context) > > For a graceful Agent restart (i.e. not a crash), I think the behavior > can be implementation-dependent. The implementation can either notify > all Clients that have data written that the state is being > preempted/torn down or it can just notify all Clients (that it knows of) > that the Agent is going down. These are important notifications to > capture in the I2RS Agent Info-Model. I don't think that either needs > to be explicitly required as the only mode. I am certainly willing to > be convinced otherwise. I think I'm on the same page with you here. If the Agent is being gracefully restarted, it flushes state, accepts no further connections, and notifies all known Clients that state is being torn down. That works for me. > > For the case of an Agent crashing, I'm quite reluctant to create a > heartbeat or persistent connection. This is a lot of complexity to add > for what should be a quite rare case. If the Agent crashes, leave the > state and the Client will get an error when it tries to connect or > otherwise request something. This does argue that on connection, the > Client should get an indication of something like an Agent boot count > /session id (and boot time). Russ's idea of storing known clients for > the agent to connect to on reboot makes sense to me. As I said in that other thread, I'm okay with the persistent list of Clients. I didn't think that would be more desirable that the heartbeat. However, I think something needs to be done to notify Clients in case of a crash. Else they might think everything is healthy when it's not. It might be minutes, hours, days, never(?) before they reconnect to learn otherwise. Joe > > I really dislike the idea of adding significant complexity to handle an > edge failure case. > > Alia > > > On Fri, Sep 13, 2013 at 12:58 AM, Joe Marcus Clarke > wrote: > > On 9/12/13 3:49 PM, Alia Atlas wrote: > > [Alia] But we (the WG) said that it was an error because we expect > > coordination > > between the applications to avoid multiple writers of the same data. > > It's not an > > error because the Agent says so - the Agent would just report back > what > > happened > > (successful write or fail due to higher priority). > > My point was that the Agent knows the priority. This isn't passed to > the RS. > > > [Alia] As Joel had said, I think we're trying to avoid the need for > > persistent > > connections just to confirm liveness. It's a heavy-handed way to > do it. > > That said, > > we could use a mechanism to determine if the RS is up and if the > associated > > Agent is up. Of course, there can be multiple Agents per RS - each > > supporting > > different services or such. For a router reboot, a Client that is > > learning topology > > would hear very quickly that a router has failed or appeared. > > > > [Alia] So - developing a liveness detection mechanism is useful. But > > what would > > be useful is the ability for the RS to notify interested clients on a > > failure. Otherwise, > > what frequency would suffice for checking - when traffic can be being > > actively dropped > > or misrouted if the Agent has failed. Also - are we designing > for the > > error-case of > > a crashed Agent rather than the normal case of a gracefully shut > down Agent? > > I was raising the point of both. In the graceful case, the Agent clears > all state and notifies all Clients. But the crash is a possibility, and > we should stipulate what should happen to state. > > I don't think we want the RS doing anything to the Clients directly. I > think perhaps an Agent->Client heartbeat is a useful thing if the Client > asks to be notified about changes. > > > > > A third model I thought of was a broker model in which the Agent > > rebooting would be a broadcast event to all subscribers. > > > > > > [Alia] I've been assuming, I guess, that Clients would hear about > router > > failures via > > the topology DM based from the IGP. > > Router failure of Agent failure? > > > > > > > In either case, I saw that the Client would have some means of > knowing > > the Agent went away. > > > > > > [Alia] I can see that if the Client knew that the Agent went away > > (ungracefully), that > > having the associated RS clean up state would be fine. I haven't yet > > heard a fully baked > > design where the client would know rapidly. We (you?) could come up > > with one, but > > that needs to be written down and agreed to. Without that, I hear > that > > the Client's state > > might suddenly disappear without the Client being able to tell - > and am > > much more comfortable > > leaving it there to be removed either via CLI or to be read and then > > written again by the Client > > when it reconnects. > > I've been kicking around the idea of a pub-sub "heartbeat." This would > give the Client awareness of the Agent's "thereness." If the heartbeat > carried a boot count, the Client might not need for multiple dropped > heartbeats before reapplying state. I don't know if this is an ideal > way to confirm liveness of the agent, though I'm happy to propose it > more formally. I think the exact approach would depend on what the > pub-sub mechanism is determined to be. > > > One other thing I haven't raised is the operator impact. How > else could > > an operator (i.e., owner/admin of a device) flush the I2RS > changes? > > There might be a malicious change or just some bad state, and > they want > > to clear that up. A restart of the Agent could do it without > reloading > > the device. > > > > > > [Alia] Why wouldn't using the CLI to flush the I2RS changes work? > > It would. I didn't realize you were okay with a graceful restart of the > Agent purging all RS state for which it is responsible. If you are, > then that is handled. > > > Also, that > > is a graceful restart of the Agent - where the Agent can tell each > > Client that all > > its written data has been preempted because the Agent is > rebooting. I'm > > also > > concerned that the behavior make sense for if/when the Agent fails. I > > could be > > persuaded not to worry about that (Agents shouldn't crash) - but I'd > > prefer not to > > mandate complexity for that case. > > I think we should. Because if there is a crash from the Agent, how then > can an admin purge state? There would no longer be a clean way to do > this. I'm trying to think what an operator might like here. > > 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 > > ---------------------------------------------------------------------------- > > -- 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 ---------------------------------------------------------------------------- From swhyte@google.com Sat Sep 14 12:41:04 2013 Return-Path: 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 BB2B811E8230 for ; Sat, 14 Sep 2013 12:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 05eim1QSnT+p for ; Sat, 14 Sep 2013 12:41:03 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 57BA611E81AB for ; Sat, 14 Sep 2013 12:41:03 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id wo20so2305556obc.27 for ; Sat, 14 Sep 2013 12:41:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ai3xokuouKtEGZP34zBvEBGv3yWYb6xrkQ+BWr0a/QM=; b=VqecjdgzfxeVEzosqUM4LJsSkiba1ObtjkfqcSMw7gckQe3/Dh4Cd+VbmCqnoKiV73 jkGKRnToFz4FTUyhmF75XYu2pUYa1QhqSUJEEDtaBmEoIhYprwir4rS0WZal7tSB1wFM ReSZU97sfCflYAYWWI0pDvELkPA9WZS+FDWW4OqOQuMLUxujBaZXi/+uuFs++cHGvn49 xYgJEQF8zjZ5K2vilm9M8rYMFTSiVtdN6N3Q8jLxOJ4BXTAAwc8tuwzauMTvkTRzi4Az 9hWe0DFZwzMOW2SEHZEVLmUMIxqa+SqpnEQ6d4FSqx7B+fzF5ht2/0Izcq6WTMZ2wVgq igLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ai3xokuouKtEGZP34zBvEBGv3yWYb6xrkQ+BWr0a/QM=; b=QA4JmqLdC9qfNOXSizdBi9/ZCRqwlIDBus+gHmo65W9sly6XyveSimKBxlD/gzhYIh Yew1BiQYr8EOZlr5V3ysNy6ZuSxJhzYG6ASfBNuihd7lYZ7CtJ5IJhmdlzemdZE7W6B4 c8+ZsBpGO3G5cBYJcfm8CXWJsMcJdCabN7RqGZCsyzv8pVOeCvM1LAthhTl7q02RxPiC I77i1WoLvBpKfMj55U00batEofHa930zLLpjAajS0f2nvFVQ3XduSZihNDOG0G5KdEqr PAlW8SFYGNnRbvQPVxo2IXU8AAIs201Ilj6DOzX4CEoQE52dnsQjB1nsIwhNrgT1jF9M NYvw== X-Gm-Message-State: ALoCoQk/pJl1lvgFm7BpyvUCedQ3BYOnSaKsMHmV4KKvc+Fb/FRj7PpMAl89gu2Z1MOXiAAhkxBkrIaCQ3qMt1nVim1NXD2iUTRfhP5EEQw7AZ2c+p7ZTKO3AWVkBdda4eIeWsWY5xTZoWS0qPEW2FiaTWGK2tRxMFg7uulhKQ5opAPMOHQ7COrTgyfjl4rbHL8vvXLrjUIL MIME-Version: 1.0 X-Received: by 10.182.226.199 with SMTP id ru7mr18175830obc.12.1379187662588; Sat, 14 Sep 2013 12:41:02 -0700 (PDT) Received: by 10.182.226.230 with HTTP; Sat, 14 Sep 2013 12:41:02 -0700 (PDT) In-Reply-To: References: <5231D77A.9050807@cisco.com> <5231DC28.9060600@cisco.com> Date: Sat, 14 Sep 2013 20:41:02 +0100 Message-ID: From: Scott Whyte To: Alia Atlas Content-Type: multipart/alternative; boundary=001a11c309aab5205d04e65d265a Cc: "i2rs@ietf.org" , Joe Marcus Clarke 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Sep 2013 19:41:04 -0000 --001a11c309aab5205d04e65d265a Content-Type: text/plain; charset=UTF-8 On Thursday, September 12, 2013, Alia Atlas wrote: > On Thu, Sep 12, 2013 at 11:22 AM, Joe Marcus Clarke > > wrote: > >> On 9/12/13 11:11 AM, Alia Atlas wrote: >> > Hi Joe, >> > >> > On Thu, Sep 12, 2013 at 11:02 AM, Joe Marcus Clarke >> > > 'jclarke@cisco.com');>>> wrote: >> > >> > On 9/12/13 10:47 AM, Alia Atlas wrote: >> > > In draft-ietf-i2rs-architecture-00 Sec 5.2, it says: >> > > >> > > "The I2RS Agent will not attempt to retain or reapply state across >> > > >> > > routing element reboot. Determination of whether state still >> > applies >> > > depends heavily on the causes of reboots, and reapplication is >> at >> > > least as likely to cause problems as it is to provide for >> correct >> > > operation. [[Editor's note: This topics needs more discussion >> > in the >> > > working group.]]" >> > > >> > > >> > > I would like to start that discussion and rapidly conclude it with >> > the needed >> > > >> > > changes (removal of the Editor's note or otherwise). >> > > >> > > >> > > My personal impression is that simplifying to just ephemeral >> state was >> > > >> > > viewed as a good idea. What do others think? Does anyone >> strongly >> > > >> > > disagree? >> > >> > I agree that ephemeral state is a good idea. But I think we need >> to be >> > a bit clearer on where the ephemerality lies. That is, if the Agent >> > goes away independent of the routing system, does the state go away? >> > Does the RS retain the state until reboot of the network element? >> > >> > IMHO, the ephemeral state should be maintained with the Agent, and >> if it >> > goes away (if it can go away independent from the RS), then the >> state >> > should go away with it. >> > >> > >> > [Alia] This is a really good point to clarify. If the I2RS Agent goes >> > away, cleaning up >> > ephemeral state that it had programmed seems like it would require an >> > additional gate-keeper >> > to keep track of that state and do the cleaning up. That seems painful >> > to me in terms of >> > complexity and storage. I am assuming an unplanned Agent departure >> > rather than an orderly >> > disabling of the Agent. If the Agent simply fails, then IMHO, the >> > ephemeral state should >> > remain - but it is no longer owned by a particular client and could be >> > overwritten... If an Agent is >> > disabled, then it can notify each client that that client's state has >> > been preempted and do an >> > orderly (?) removal of the state. The gotcha with the orderly removal >> > of the state would be understanding >> > the dependencies of the state so that it can be cleanly removed. >> > >> > [Alia] So, I think we're picturing almost opposite things for this >> > behavior - possibly based upon the >> > particular case. What do you think? >> >> See my response to Joel. I think we have to deal with this complexity >> because if we don't and the Agent goes away, how could Clients then come >> in to remove their state? That is, the RS retains the Agent-programmed >> state, but when the Agent reboots, it has no state. At the worst, we >> have RS state that a Client cannot manipulate. At best, we would open >> RS state to Clients that did not make the original change. >> > > [Alia] I don't think that we've included locking for I2RS - so I can't see > how we'd have > RS that a client cannot manipulate. Whether state is removed(changed back > to the > default) or left, we will definitely have the ability for a Client to add > or change the RS > state. > I don't understand why ephemeral state is held by the agent. The client has to track what it sent to which agent. Surely a client could easily be informed an agent has lost its brain, and ask for a dump of the RS state it is eligible to receive from that agent? Failing in place is a very useful thing, and what's of interest here is the RS state not the agent state. > > >> I think we have to say, to an implementor, if the Agent goes away, the >> RS must handle cleaning up all state installed by that Agent. >> > > [Alia] I think that it could be either way - that the state remains but > can be overwritten > or that the RS has to clean up the state. I'm concerned that in the RS > cleans up the state > case, there is no way for the Client to learn that its state has been > removed (assuming a > failure on the part of the Agent rather than an orderly removal). I'd > prefer to see the state > remain for that reason for the Agent-failure case. What do you think? > > Alia > > >> >> Joe >> >> > >> > Alia >> > >> > > >> > > >> > > Thanks, >> > > >> > > Alia (WG-chair hat off) >> > > >> > > >> > > >> > > _______________________________________________ >> > > i2rs mailing list >> > > i2rs@ietf.org > i2rs@ietf.org > >> > > https://www.ietf.org/mailman/listinfo/i2rs >> > > >> > >> > >> > -- >> > 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 > 'jclarke@cisco.com');> > 'cvml', 'jclarke@cisco.com');>> >> > >> > >> ---------------------------------------------------------------------------- >> > >> > >> >> >> -- >> 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 > 'jclarke@cisco.com');> >> >> >> ---------------------------------------------------------------------------- >> > > -- There was never any more inception than there is now, Nor any more youth or age than there is now, And will never be any more perfection than there is now, Nor any more heaven or hell than there is now. -Walt Whitman --001a11c309aab5205d04e65d265a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thursday, September 12, 2013, Alia Atlas wrote:
On Thu, Sep 12, 2013 at 11:22 AM, Joe M= arcus Clarke <jclarke@cisco.com= > wrote:
On 9/12/13 11:11 AM, Alia Atlas wrote:<= br> > Hi Joe,
>
> On Thu, Sep 12, 2013 at 11:02 AM, Joe Marcus Clarke <jclarke@cisco.com
> <mailto:jclarke@cisco.com>= ;> wrote:
>
> =C2=A0 =C2=A0 On 9/12/13 10:47 AM, Alia Atlas wrote:
> =C2=A0 =C2=A0 > In draft-ietf-i2rs-architecture-00 Sec 5.2, it says= :
> =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 > "The I2RS Agent will not attempt to retain or = reapply state across
> =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 > =C2=A0 =C2=A0routing element reboot. =C2=A0Determin= ation of whether state still
> =C2=A0 =C2=A0 applies
> =C2=A0 =C2=A0 > =C2=A0 =C2=A0depends heavily on the causes of reboo= ts, and reapplication is at
> =C2=A0 =C2=A0 > =C2=A0 =C2=A0least as likely to cause problems as i= t is to provide for correct
> =C2=A0 =C2=A0 > =C2=A0 =C2=A0operation. =C2=A0[[Editor's note: = This topics needs more discussion
> =C2=A0 =C2=A0 in the
> =C2=A0 =C2=A0 > =C2=A0 =C2=A0working group.]]"
> =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 > I would like to start that discussion and rapidly c= onclude it with
> =C2=A0 =C2=A0 the needed
> =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 > changes (removal of the Editor's note or otherw= ise).
> =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 > My personal impression is that simplifying to just = ephemeral state was
> =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 > viewed as a good idea. =C2=A0What do others think? = =C2=A0Does anyone strongly
> =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 > disagree?
>
> =C2=A0 =C2=A0 I agree that ephemeral state is a good idea. =C2=A0But I= think we need to be
> =C2=A0 =C2=A0 a bit clearer on where the ephemerality lies. =C2=A0That= is, if the Agent
> =C2=A0 =C2=A0 goes away independent of the routing system, does the st= ate go away?
> =C2=A0 =C2=A0 Does the RS retain the state until reboot of the network= element?
>
> =C2=A0 =C2=A0 IMHO, the ephemeral state should be maintained with the = Agent, and if it
> =C2=A0 =C2=A0 goes away (if it can go away independent from the RS), t= hen the state
> =C2=A0 =C2=A0 should go away with it.
>
>
> [Alia] This is a really good point to clarify. =C2=A0If the I2RS Agent= goes
> away, cleaning up
> ephemeral state that it had programmed seems like it would require an<= br> > additional gate-keeper
> to keep track of that state and do the cleaning up. =C2=A0 That seems = painful
> to me in terms of
> complexity and storage. =C2=A0I am assuming an unplanned Agent departu= re
> rather than an orderly
> disabling of the Agent. =C2=A0 =C2=A0 If the Agent simply fails, then = IMHO, the
> ephemeral state should
> remain - but it is no longer owned by a particular client and could be=
> overwritten... =C2=A0If an Agent is
> disabled, then it can notify each client that that client's state = has
> been preempted and do an
> orderly (?) removal of the state. =C2=A0The gotcha with the orderly re= moval
> of the state would be understanding
> the dependencies of the state so that it can be cleanly removed.
>
> [Alia] So, I think we're picturing almost opposite things for this=
> behavior - possibly based upon the
> particular case. =C2=A0 What do you think?

See my response to Joel. =C2=A0I think we have to deal with thi= s complexity
because if we don't and the Agent goes away, how could Clients then com= e
in to remove their state? =C2=A0That is, the RS retains the Agent-programme= d
state, but when the Agent reboots, it has no state. =C2=A0At the worst, we<= br> have RS state that a Client cannot manipulate. =C2=A0At best, we would open=
RS state to Clients that did not make the original change.
=

[Alia] I don't think that we've included lockin= g for I2RS - so I can't see how we'd have
RS that a clien= t cannot manipulate. =C2=A0Whether state is removed(changed back to the
default) =C2=A0or left, we will definitely have the ability for a Clie= nt to add or change the RS
state.

I don't understand why ephemeral state is held= by the agent. =C2=A0The client has to track what it sent to which agent. = =C2=A0Surely a client could easily be informed an agent has lost its brain,= and ask for a dump of the RS state it is eligible to receive from that age= nt? =C2=A0Failing in place is a very useful thing, and what's of intere= st here is the RS state not the agent state.

=C2=A0
=C2=A0
I think we have to say, to an implementor, if the Agent goes away, the
RS must handle cleaning up all state installed by that Agent.

[Alia] I think that it could be either way - that th= e state remains but can be overwritten
or that the RS has to clea= n up the state. =C2=A0I'm concerned that in the RS cleans up the state<= /div>
case, there is no way for the Client to learn that its state has been = removed (assuming a
failure on the part of the Agent rather than = an orderly removal). =C2=A0I'd prefer to see the state
remain= for that reason for the Agent-failure case. =C2=A0What do you think?

Alia
=C2=A0

Joe =C2=A0

>
> Alia
>
> =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 > Thanks,
> =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 > Alia (WG-chair hat off)
> =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 > _______________________________________________
> =C2=A0 =C2=A0 > i2rs mailing list
> =C2=A0 =C2=A0 > i2rs@ietf.org <mailto:<= a href=3D"javascript:_e({}, 'cvml', 'i2rs@ietf.org');" targ= et=3D"_blank">i2rs@ietf.org>
> =C2=A0 =C2=A0 > https://www.ietf.org/mailman/listinfo/i2rs > =C2=A0 =C2=A0 >
>
>
> =C2=A0 =C2=A0 --
> =C2=A0 =C2=A0 Joe Marcus Clarke, CCIE #5384, =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> =C2=A0 =C2=A0 SCJP, SCSA, SCNA, SCSECA, VCP =C2=A0 =C2=A0 =C2=A0 =C2= =A0||||| =C2=A0 =C2=A0 =C2=A0|||||
> =C2=A0 =C2=A0 Distinguished Services Engineer ..:|||||||||::|||||||||:= ..
> =C2=A0 =C2=A0 Phone: +1 (919) 392-2867 <tel:%2B= 1%20%28919%29%20392-2867> =C2=A0 =C2=A0 =C2=A0 =C2=A0 c
> =C2=A0 =C2=A0 i s c o =C2=A0S y s t e m s
> =C2=A0 =C2=A0 Email: jclarke@cisco.com &l= t;mailto:jclarke@cisco.com>
>
> =C2=A0 =C2=A0 --------------------------------------------------------= --------------------
>
>


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

---------------------------------------------------------------------------= -



--
There was never any more inception than there i= s now,
Nor any more youth or age than there is now,
And will never be= any more perfection than there is now,
Nor any more heaven or hell than= there is now.
=C2=A0 -Walt Whitman
--001a11c309aab5205d04e65d265a-- From swhyte@google.com Sat Sep 14 12:41:05 2013 Return-Path: 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 3786911E81AB for ; Sat, 14 Sep 2013 12:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 C+MSc1BADH2U for ; Sat, 14 Sep 2013 12:41:04 -0700 (PDT) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD1311E8227 for ; Sat, 14 Sep 2013 12:41:04 -0700 (PDT) Received: by mail-oa0-f49.google.com with SMTP id i7so2361631oag.22 for ; Sat, 14 Sep 2013 12:41:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AQJp1rE42wyNHRfBxPWHFBftVwa1s+VBAq4SprI1Qlc=; b=AWPIQX1MhTpwUM0LAezif86ruCxxZynjRHIfVIgpvZJisR97tR6V1gi62TjyinjLSJ MJ/I66cqNAhGZUO3WXh2GCWo3/mko4BrTyUFEY9ld4JtB4CUAmpQ+IyyvLkdpOoeH7wm fbjwT5/AihseAvjCcHBL4F0R2tCqdpyY9MaOM4kcuCksUe0HIeDjFs+trt65LCGkaFXO BK5+vPO1S0DXqt42DImDb3dT9kHmzhLubEd41adiEt7IAF3T5HXtrw7iFwd12U3hp9iy CqF+7eX0q8pN26Z4uEEA9vz11tonVaSXmeCldA4Z7uHjtXlIhSmkhgSimDHRoarGr3KW gfdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=AQJp1rE42wyNHRfBxPWHFBftVwa1s+VBAq4SprI1Qlc=; b=Hbza9snVJaD5owbyr8eMVdShXDG/n47+vG5boVUHUIRXzMJjw9xdhV7vNvMB2Drb/3 lRJweSzJYqox6ZmOLiM6KdvEDOAe2LGi7CeJzSbTHZkF2ZtAblZzvENoBUDHMW6IDkX+ 38cos5CaHwfVZ8X2EaBSVjBEGaC7lDiaMVyx/vSq2ICXtL9FKh/CRP7nV/Y2oBEB64xF 2pNhyJvySUJnn17bwc7C3ora8P8Pp9R45UeNfoGPopZVMDEbILeC0zWFpv8gCs2uIwYZ nBE5SpV6sM5vM1iKbfSQ6BpfJQVGVP+yBbCLvrKsOAVI3PsOluBR5TfTZB/qK/3dDvWv +JFw== X-Gm-Message-State: ALoCoQll6xb1JKs8rv22i/GtStBtpCAV77JPLFX0S3LfThDtLtNiM3NBtYvpleOLWCw55hvoreM7nrThIRpRt8QWjH2XYxDTyIpTtSX5c+85aFIW/gplen7OqYg7Lf8WdFQ9pocKMPPOGOIPLk/nb/A5YmW5+7MKsvcwBL9vAFFTk6tktRRUxYQGO37ygkjzOBhNusr4Dqkr MIME-Version: 1.0 X-Received: by 10.60.93.67 with SMTP id cs3mr18368957oeb.12.1379187663757; Sat, 14 Sep 2013 12:41:03 -0700 (PDT) Received: by 10.182.226.230 with HTTP; Sat, 14 Sep 2013 12:41:03 -0700 (PDT) In-Reply-To: References: Date: Sat, 14 Sep 2013 20:41:03 +0100 Message-ID: From: Scott Whyte To: Alia Atlas Content-Type: multipart/alternative; boundary=047d7b33d176c6f6ba04e65d26a5 Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Architecture Discussion 5: Client Redundancy X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Sep 2013 19:41:05 -0000 --047d7b33d176c6f6ba04e65d26a5 Content-Type: text/plain; charset=UTF-8 On Thursday, September 12, 2013, Alia Atlas wrote: > In draft-ietf-i2rs-architecture-00 Sec 6.4.1: > > "I2RS must support client redundancy. At the simplest, this can be > > handled by having a primary and a backup network application that > both use the same client identity and can successfully authenticate > as such. Since I2RS does not require a continuous transport > connection and supports multiple transport sessions, this can provide > some basic redundancy. However, it does not address concerns for > > troubleshooting and accountability about knowing which network > application is actually active. At a minimum, basic transport > information about each connection and time can be logged with the > identity. Further discussion is necessary to determine whether > additional client identification information is necessary.[[Editor's > note: This requires more discussion in the working group.]]" > > > I would like to start this discussion. During and after the Berlin IETF, there > > was significant discussion on the list. I tried to capture the ideas that were > > expressed then. Is what is in the draft now sufficient? How should it be improved > > upon? > > Per the pub-sub discussion on the other threads, I think this is best solved outside of I2RS. -Scott > > Thanks, > > Alia (WG-Chair hat off) > > -- There was never any more inception than there is now, Nor any more youth or age than there is now, And will never be any more perfection than there is now, Nor any more heaven or hell than there is now. -Walt Whitman --047d7b33d176c6f6ba04e65d26a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thursday, September 12, 2013, Alia Atlas wrote:
In draft-ietf-i2rs-architecture-00 Sec 6.4.1:

"I2RS must support clie= nt redundancy. At the simplest, this can be
   handled by having a primary and a backup network applic=
ation that
   both use the same client identity and can successfully authenticate
   as such.  Since I2RS does not require a continuous transport
   connection and supports multiple transport sessions, this can provide
   some basic redundancy.  However, it does not address concerns for

   troubleshooting and accountability ab=
out knowing which network
   application is actually active.  At a minimum, basic transport
   information about each connection and time can be logged with the
   identity.  Further discussion is necessary to determine whether
   additional client identification information is necessary.[[Editor's
   note: This requires more discussion in the working group.]]"=


I would like to start this disc=
ussion.  During and after the Berlin IETF, there
was significant discussion on the list.  I tried to capture the ideas th=
at were
expressed then.  Is what is in the draft now sufficient?  =
How should it be improved
upon?
<= /blockquote>

Per the pub-sub discussion on the other thr= eads, I think this is best solved outside of I2RS.

-Scott
=C2=A0



Thanks,
Alia (WG=
-Chair hat off)


--
There was never any more inception than there i= s now,
Nor any more youth or age than there is now,
And will never be= any more perfection than there is now,
Nor any more heaven or hell than= there is now.
=C2=A0 -Walt Whitman
--047d7b33d176c6f6ba04e65d26a5-- From swhyte@google.com Sat Sep 14 12:41:05 2013 Return-Path: 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 5297411E8227 for ; Sat, 14 Sep 2013 12:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 TQkW+7t+aJAn for ; Sat, 14 Sep 2013 12:41:04 -0700 (PDT) Received: from mail-oa0-x233.google.com (mail-oa0-x233.google.com [IPv6:2607:f8b0:4003:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id D60C111E8224 for ; Sat, 14 Sep 2013 12:41:03 -0700 (PDT) Received: by mail-oa0-f51.google.com with SMTP id h1so2355635oag.24 for ; Sat, 14 Sep 2013 12:41:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VL8zHYoXVT1kbYpLpLtZgkO0M1yDrxQb+Mjm6K4BRbI=; b=RbsW5hZkTN+bsnn+vijX5chaVOH0+ui1zddqQNIxD/plkDqghXeSyh+CX7nlO6cgX0 GhKEb+U3dCKAmfcjr24RyCGcfZSenc153b/hoIYo2uWuGdebj/VlVAoYPMi6sflMpR8C L75Br2xDp1yVdxMNM/UErEKHd7hXAwPYhqKT/yDD6YC7F5tYtGn2RHXbe3MVKlqGrr+K fzu1PLWJsDl58EVNtaJv7nacqs/kPU00A4yDhFQzjxD9hsUSRcHH4I5dXNT5lBRlaLUL /lAiyX2BIPg0blBCPHfaabpZRGqsR0izCwFET2LhqI5OrnQ9ZU4qKCFD++pt9z6x1EaT Atgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=VL8zHYoXVT1kbYpLpLtZgkO0M1yDrxQb+Mjm6K4BRbI=; b=g4oTd21dvbvR15NMbj5kKQUhl1obP/e/ov3er2sZJ1H9Et8X3FabjW9xhmTVjFHsLx dCYcN52ZLCAXg2SHzKeQHak4Uowx5EEZwgvZ9lHkBvon62eyEANeAE51f9kAo5vRHvcg vj4h6q37sZXUxjraCOFq/ZbTv/vW8TkxqUB2ovDohqSWY6rh7HW7xyCrSWnzbKLiu+wQ 4/h76SokPK9ioVNOEJfY1L5Q/ql8Kr6tDvVw0xKUk7kHCr94WdEIBkW1y7r7MI+om+FT +VNm5x4F+lXlRQvmT5uy6CpfqZ65HXeS7Iwoljw0BDXTe9HnRuft2xHaSz+W2QpmDAom oySw== X-Gm-Message-State: ALoCoQnxgopDe7zaXzjCz28Z+Opr4E+1tfLwGN48EB8i5ikpqIM1msdixXosvbz7MYscrKryi5CXaOhBuQFxlPCND+ZumtHoMXbvonAiOQCDgzz54UkqUuKBFlLVvzyayVWw6twuuXisi/lvPyNFL0uSKP4SaxloQ5wwAo3xDsz351P1A02cE0nw687r1cr+X5jUrQCIprQn MIME-Version: 1.0 X-Received: by 10.182.114.231 with SMTP id jj7mr18495351obb.33.1379187663213; Sat, 14 Sep 2013 12:41:03 -0700 (PDT) Received: by 10.182.226.230 with HTTP; Sat, 14 Sep 2013 12:41:03 -0700 (PDT) In-Reply-To: References: <5231D77A.9050807@cisco.com> <5231DC28.9060600@cisco.com> <5231E14E.5020605@cisco.com> Date: Sat, 14 Sep 2013 20:41:03 +0100 Message-ID: From: Scott Whyte To: Alia Atlas Content-Type: multipart/alternative; boundary=001a11c2eb42beba3104e65d2678 Cc: "i2rs@ietf.org" , Joe Marcus Clarke 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Sep 2013 19:41:05 -0000 --001a11c2eb42beba3104e65d2678 Content-Type: text/plain; charset=UTF-8 On Thursday, September 12, 2013, Alia Atlas wrote: > Hi Joe, > > More in-line (good to have the conversation) > > On Thu, Sep 12, 2013 at 11:44 AM, Joe Marcus Clarke > > wrote: > >> On 9/12/13 11:31 AM, Alia Atlas wrote: >> > [Alia] I don't think that we've included locking for I2RS - so I can't >> > see how we'd have >> > RS that a client cannot manipulate. Whether state is removed(changed >> > back to the >> > default) or left, we will definitely have the ability for a Client to >> > add or change the RS >> > state. >> >> Fair enough. >> >> > >> > >> > I think we have to say, to an implementor, if the Agent goes away, >> the >> > RS must handle cleaning up all state installed by that Agent. >> > >> > >> > [Alia] I think that it could be either way - that the state remains but >> > can be overwritten >> > or that the RS has to clean up the state. I'm concerned that in the RS >> > cleans up the state >> > case, there is no way for the Client to learn that its state has been >> > removed (assuming a >> > failure on the part of the Agent rather than an orderly removal). I'd >> > prefer to see the state >> > remain for that reason for the Agent-failure case. What do you think? >> >> I think the risk of an Agent reboot allowing Client B to change Client >> A's state warrants the RS cleanup. >> > > [Alia] The risk that client B comes and changes the state after an Agent > reboot justifies the RS cleanup of that state before?? Remember that > Client A and B aren't supposed to be overwriting each other's data. We've > defined that as an error case and that policy between the clients should > prevent it. > > >> Plus, if the Client is subscribed to a pub-sub bus then it could >> presumably learn about an Agent cold start via a published message. At >> that point, the client could re-establish its state to the Agent. >> > > [Alia] Hmm, I know there was a draft discussed about pub-sub methods in > general - but I don't think that we've really nailed down how pub-sub would > work. Absent anything, I'd assume that the I2RS agent is whom the client > registers with to get its notifications. Now, if we want to have a > different system being a bus (with the scale implications there), that > might be different - but I don't think we've really talked about that. So, > my assumption is that the Agent provides the notifications to Clients that > have registered - and when the Agent reboots, there are no Clients > registered to get the notifications. If you have a different model (or > different thoughts on what to do for the pub-sub), want to start that > discussion (perhaps in a different thread)? > A pub-sub method makes a lot of sense here. It offloads reliability out of the I2RS protocols and into the systems supporting client-agent communications. 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 also think we need to consider that SDN enables a distributed control plane, but IMO its necessary for I2RS to provide specific transport / format requirements for all the various latency cases. Giving SDN implementors the ability to solve their specific needs via a standardized way to negotiate capabilities seems to have much broader utility. In the same vein, I don't think we can just limit the information an I2RS agent provides to traditional "routing sytem" control plane state. For example, data plane state greatly impacts TE decisions. Someone may want to get 3000+ interface stats off a box every 30ms in order to do very real-time TE, and someone else may want that data to do billing. Let's enable both at the same time. > > >> If the Client is not part of the bus, it could periodically connect to >> the Agent and learn that it was rebooted via the protocol...yeah, this >> sounds a bit like SNMP, but it seems reasonable to me. >> > > [Alia] It doesn't sound reasonable to me... at least not to avoid what > should be an error condition. Can we discuss more? Do you have additional > justification for the significant added complexity. > Given push and pull capabilities, having the agent push a notification that initiates some kind of state synchronization on the client would be ideal. Push capabilities have a lot of nice features beyond a heart-beat, but that probably does deserve another thread. -Scott > > Regards, > Alia > > >> >> 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 > 'jclarke@cisco.com');> >> >> >> ---------------------------------------------------------------------------- >> > > -- There was never any more inception than there is now, Nor any more youth or age than there is now, And will never be any more perfection than there is now, Nor any more heaven or hell than there is now. -Walt Whitman --001a11c2eb42beba3104e65d2678 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thursday, September 12, 2013, Alia Atlas wrote:
Hi Joe,
<= br>More in-line (good to have the conversation)

On Thu, Sep 12, 2013 at 11:44 AM, Joe Marcus= Clarke <jclarke@cisco.com><= /span> wrote:
On 9/12/13 11:31 AM, Alia Atlas wrote:<= br> > [Alia] I don't think that we've included locking for I2RS - so= I can't
> see how we'd have
> RS that a client cannot manipulate. =C2=A0Whether state is removed(cha= nged
> back to the
> default) =C2=A0or left, we will definitely have the ability for a Clie= nt to
> add or change the RS
> state.

Fair enough.

>
>
> =C2=A0 =C2=A0 I think we have to say, to an implementor, if the Agent = goes away, the
> =C2=A0 =C2=A0 RS must handle cleaning up all state installed by that A= gent.
>
>
> [Alia] I think that it could be either way - that the state remains bu= t
> can be overwritten
> or that the RS has to clean up the state. =C2=A0I'm concerned that= in the RS
> cleans up the state
> case, there is no way for the Client to learn that its state has been<= br> > removed (assuming a
> failure on the part of the Agent rather than an orderly removal). =C2= =A0I'd
> prefer to see the state
> remain for that reason for the Agent-failure case. =C2=A0What do you t= hink?

I think the risk of an Agent reboot allowing Client B to change Clien= t
A's state warrants the RS cleanup.

= [Alia] The risk that client B comes and changes the state after an Agent re= boot justifies the RS cleanup of that state before?? =C2=A0Remember that Cl= ient A and B aren't supposed to be overwriting each other's data. = =C2=A0We've defined that as an error case and that policy between the c= lients should prevent it. =C2=A0
=C2=A0
Plus, if the Client is subs= cribed to a pub-sub bus then it could
presumably learn about an Agent cold start via a published message. =C2=A0A= t
that point, the client could re-establish its state to the Agent.

[Alia] Hmm, I know there was a draft discussed a= bout pub-sub methods in general - but I don't think that we've real= ly nailed down how pub-sub would work. =C2=A0Absent anything, I'd assum= e that the I2RS agent is whom the client registers with to get its notifica= tions. =C2=A0Now, if we want to have a different system being a bus (with t= he scale implications there), that might be different - but I don't thi= nk we've really talked about that. =C2=A0So, my assumption is that the = Agent provides the notifications to Clients that have registered - and when= the Agent reboots, there are no Clients registered to get the notification= s. =C2=A0If you have a different model (or different thoughts on what to do= for the pub-sub), want to start that discussion (perhaps in a different th= read)?

A pub-sub method makes a= lot of sense here. =C2=A0It offloads reliability out of the I2RS protocols= and into the systems supporting client-agent communications.
I'm not sure I agree that a client is a direct subscriber, a= t least in the sense that brokers are very useful for scalability. =C2=A0Us= ing 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. =C2=A0It might be very = nice to have the broker-agent communication be UDP and the broker-client co= mmunication be TCP for example, where I purposefully put the broker topolog= ically close to the agents and the clients can be hierarchically distribute= d throughout the network.

I also think we need to consider that SDN enables a dis= tributed control plane, but IMO its necessary for I2RS to provide specific = transport / format requirements for all the various latency cases. =C2=A0Gi= ving SDN implementors the ability to solve their specific needs via a stand= ardized way to negotiate capabilities seems to have much broader utility.

In the same vein, I don't think we can just limit t= he information an I2RS agent provides to traditional "routing sytem&qu= ot; control plane state. =C2=A0For example, data plane state greatly impact= s TE decisions. =C2=A0Someone may want to get 3000+ interface stats off a b= ox every 30ms in order to do very real-time TE, and someone else may want t= hat data to do billing. =C2=A0Let's enable both at the same time.

=C2=A0
=C2=A0
If the Client is not part o= f the bus, it could periodically connect to
the Agent and learn that it was rebooted via the protocol...yeah, this
sounds a bit like SNMP, but it seems reasonable to me.

[Alia] It doesn't sound reasonable to me... at least no= t to avoid what should be an error condition. =C2=A0Can we discuss more? = =C2=A0Do you have additional justification for the significant added comple= xity.

Given push and pull capa= bilities, having the agent push a notification that initiates some kind of = state synchronization on the client would be ideal. =C2=A0Push capabilities= have a lot of nice features beyond a heart-beat, but that probably does de= serve another thread.

-Scott

=C2=A0

Regards,
Alia
=C2=A0

Joe

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

---------------------------------------------------------------------------= -



--
There was never any more inception than there i= s now,
Nor any more youth or age than there is now,
And will never be= any more perfection than there is now,
Nor any more heaven or hell than= there is now.
=C2=A0 -Walt Whitman
--001a11c2eb42beba3104e65d2678-- From swhyte@google.com Sat Sep 14 12:41:05 2013 Return-Path: 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 AFBA711E81AB for ; Sat, 14 Sep 2013 12:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 iuHQedsjXVLU for ; Sat, 14 Sep 2013 12:41:05 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id AF2BE11E822E for ; Sat, 14 Sep 2013 12:41:04 -0700 (PDT) Received: by mail-ob0-f171.google.com with SMTP id wm4so2282291obc.16 for ; Sat, 14 Sep 2013 12:41:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BAr1MADVVGRNBU6i+i2RrMFR+KVx8NFMYG5nRCr8zIM=; b=lVZWZXw82z84wCwZGu2pkYLcJop0ovjSN5l8pkeTgRJiXXA9pu07P7lxVHTAOZsukQ 9nqpj2kYMISmipTuy3uemx8oI1/xYTWIf6M8IJ8dR59tHtgbTJGWmvfWrJXNJE6UtQod Bda7k9agpvTinqVadherSnSaSwWLtj3j92cTygLx/ViWWiQJ/haJepnWWSgEdfQ+8WzA 3vbu8w6Mv9/wW/iIBTUqCLTBTGHPJzqy8WEH6MvA++N+iG5kzl/U3aMliE/lzFU4XosX mTWAIpoBJyeTN8AF5Lb0iN7o9JKXc5jX143S6g9bIstpPND1mLb5Wm8CvJp/+FmqOhJU OLvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BAr1MADVVGRNBU6i+i2RrMFR+KVx8NFMYG5nRCr8zIM=; b=BalElSjrI1uimArF4ap/lGDJTF7FUwmQli5qBXPvonpV1heIep6fFh4PX+EmBFAdaj C+S3brgZp4b4gBzWu/NUNTdQ8oOLPdnVtI1KhTxb2TGgTXNTHj7Jbj4vnFUscF/CPcEn BJY3+isew20Ub5oGCI5VNaB8tCi0INp5lLbmOCXs5vZFM/DTAWRoJCLn3Aylypc7tSRg ZRbabC0iT52IQBfvXk68mIOWmxjXWKiiw5LuW17faSZQvVFiyK/Ns8MTK7e5Oe0mRrTc hJk8k5iztmaH+JFTMFlPU2rcFllvYyhCzxj3CjLoqUFNjKnBxZ9aA4aM7E96aXjO47D2 OOvA== X-Gm-Message-State: ALoCoQndpESSWkrgZURguOJm9KXDUJYpkqvDLNp/vaX8ePE/3IuwTfDuBWyndORsdXzRUUXPt8EYLA/gFZwyFpuCCSfYZpMHrzJW6whsO1etslE4dB6b2Uctl6B9xiaeDpo1SoUtOQAdahawkY0B1omsS2Z6gC6eZV1L2JDz91yISwlEcO0s5szBmy1TuDZWRfRxjoaJ5Lmb MIME-Version: 1.0 X-Received: by 10.182.88.129 with SMTP id bg1mr18092485obb.36.1379187664243; Sat, 14 Sep 2013 12:41:04 -0700 (PDT) Received: by 10.182.226.230 with HTTP; Sat, 14 Sep 2013 12:41:04 -0700 (PDT) In-Reply-To: References: Date: Sat, 14 Sep 2013 20:41:04 +0100 Message-ID: From: Scott Whyte To: Alia Atlas Content-Type: multipart/alternative; boundary=089e01184a92ce64c604e65d26dc Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Architecture Discussion 3: Operations are Immediate and continuing X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Sep 2013 19:41:05 -0000 --089e01184a92ce64c604e65d26dc Content-Type: text/plain; charset=UTF-8 On Thursday, September 12, 2013, Alia Atlas wrote: > In draft-ietf-i2rs-architecture-00 Sec. 5.2.1: > > " Given that the complexity of possible conditions is very large, and > > that some conditions may even cross network element boundaries, > clearly some degree of handling must be provided on the I2RS client. > As such, in this architecture it is assumed that all the complexity > associated with this should be left to the I2RS client. This > architectural view does mean that reliability of the communication > path between the I2RS client and I2RS agent is critical. [[Editor's > note: This requires more discussion in the working group.]]" > > > I would like to start this discussion and conclude it rapidly. > > > Personally, I have heard that this is a good simplification. Removing the > > ability to specify the start-time and end-time of an operation adds complexity > > and we don't clearly have use-cases that need it. Does anyone have a different > > perspective? > > I support this simplification. -Scott > > Thanks, > > Alia (WG-chair hat off) > > > -- There was never any more inception than there is now, Nor any more youth or age than there is now, And will never be any more perfection than there is now, Nor any more heaven or hell than there is now. -Walt Whitman --089e01184a92ce64c604e65d26dc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thursday, September 12, 2013, Alia Atlas wrote:
In draft-ietf-i2rs-architecture-00 Sec. 5.2.1:

" Given that the comp= lexity of possible conditions is very large, and
   that some conditions may even cross network element bou=
ndaries,
   clearly some degree of handling must be provided on the I2RS client.
   As such, in this architecture it is assumed that all the complexity
   associated with this should be left to the I2RS client.  This
   architectural view does mean that reliability of the communication
   path between the I2RS client and I2RS agent is critical.  [[Editor's
   note: This requires more discussion in the working group.]]"=


I would like to start this disc=
ussion and conclude it rapidly.



Personally, I have heard that this is a good =
simplification.  Removing the=C2=A0
ability to specify the start-ti=
me and end-time of an operation adds complexity
perspective?

I support this simplification.

-Scott
=C2=A0




Thanks,
Alia (WG=
-chair hat off)



--
There was never any more inception than there i= s now,
Nor any more youth or age than there is now,
And will never be= any more perfection than there is now,
Nor any more heaven or hell than= there is now.
=C2=A0 -Walt Whitman
--089e01184a92ce64c604e65d26dc-- From swhyte@google.com Sat Sep 14 12:47:43 2013 Return-Path: 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 61F7611E8227 for ; Sat, 14 Sep 2013 12:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] 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 P-EhU0u0jQcx for ; Sat, 14 Sep 2013 12:47:42 -0700 (PDT) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 9053611E8224 for ; Sat, 14 Sep 2013 12:47:42 -0700 (PDT) Received: by mail-oa0-f41.google.com with SMTP id j6so2409371oag.28 for ; Sat, 14 Sep 2013 12:47:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GXXbNmwJ0C1NUdrs2FJrfQqvRYkVzfIq6dqBvYFOUzI=; b=a7Bis8FPo2G3LBGZbl69F9jVwIPuNv8ghFNLz0POD2GqwqoLEU4ivPdpNfEQjornjW egX17qVl9oVxAnfkdvfHUJV18Wbiklt7zJWdYM56tGrt/lPCF/Nwxpe6Gcra2MSsz7+1 ydtpnjOENJmxVbgy17mHxldck3LqZ/ihfsY0tAyg9QruZkcY77Vbrp43pfHF6ncI5Uo9 lepEBYU+F/7r3hiEMyzbe2hCZDkLnRRG2AhBNBopcMBCsb2AToJ0y7dGTntSb0oduyah ge43DLx/Wc4x7mRm9nzibXvUvTGLHS5NWPRV94NJh/aTEfXNn+N5N+kDnpx2d+g0cR2P Emhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GXXbNmwJ0C1NUdrs2FJrfQqvRYkVzfIq6dqBvYFOUzI=; b=bum/lB5UFiGgTCBC95vLpfn5kgJaxYByj+ijK5zgcgcHgGYHNnvERH13JmxUK4pZZJ eLhaujp+kKOUXre8r+YJvRIbLxwXvzrESTCDWma8wWiHZDQU2DDFVbYK6bBj7L8oshA1 fumy7tHC6QL4rTKETugAmlL1A6dE8PCi+23v/qgUpA0fG3WGE1ZW0Z86SJBcEhCMLKn+ xmgITNXqilpMwXpw8rFqbj7ON7bAnmCna5ofKZTnn2KivgO6TPd3lAmyXVrAYVbl7t7V MlmtPw3Reqxab1s+irkz+alATJS12MG0KgsNPfMJrhEHmjzW+lkaxqzSNLM919YYD7UX +QEg== X-Gm-Message-State: ALoCoQmSUvOptMgQr4hkkybDgqFEZv8PjIQBrxgPxMaqmMIOqvFWvP4OwgfvVslhf8GL3dtj/HzRkIsLVZkW+vqCWKlBBdmNNdJzj6UIlLMVNLJD9wACpHWqVzCZ2jXs/+sX7wrdYzdI9Tclm38Yj+6azcCmO3vF719/GqoJv503QEpIbYMLeS7roBadSTC5uSbchTRYlVkg MIME-Version: 1.0 X-Received: by 10.60.58.71 with SMTP id o7mr2321379oeq.51.1379188062065; Sat, 14 Sep 2013 12:47:42 -0700 (PDT) Received: by 10.182.226.230 with HTTP; Sat, 14 Sep 2013 12:47:41 -0700 (PDT) In-Reply-To: References: <5231D77A.9050807@cisco.com> <5231DC28.9060600@cisco.com> <5231E14E.5020605@cisco.com> Date: Sat, 14 Sep 2013 20:47:41 +0100 Message-ID: From: Scott Whyte To: Alia Atlas Content-Type: text/plain; charset=UTF-8 Cc: "i2rs@ietf.org" , Joe Marcus Clarke 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Sep 2013 19:47:43 -0000 On Sat, Sep 14, 2013 at 8:41 PM, Scott Whyte wrote: > > > On Thursday, September 12, 2013, Alia Atlas wrote: >> >> Hi Joe, >> >> More in-line (good to have the conversation) >> >> On Thu, Sep 12, 2013 at 11:44 AM, Joe Marcus Clarke >> wrote: >>> >>> On 9/12/13 11:31 AM, Alia Atlas wrote: >>> > [Alia] I don't think that we've included locking for I2RS - so I can't >>> > see how we'd have >>> > RS that a client cannot manipulate. Whether state is removed(changed >>> > back to the >>> > default) or left, we will definitely have the ability for a Client to >>> > add or change the RS >>> > state. >>> >>> Fair enough. >>> >>> > >>> > >>> > I think we have to say, to an implementor, if the Agent goes away, >>> > the >>> > RS must handle cleaning up all state installed by that Agent. >>> > >>> > >>> > [Alia] I think that it could be either way - that the state remains but >>> > can be overwritten >>> > or that the RS has to clean up the state. I'm concerned that in the RS >>> > cleans up the state >>> > case, there is no way for the Client to learn that its state has been >>> > removed (assuming a >>> > failure on the part of the Agent rather than an orderly removal). I'd >>> > prefer to see the state >>> > remain for that reason for the Agent-failure case. What do you think? >>> >>> I think the risk of an Agent reboot allowing Client B to change Client >>> A's state warrants the RS cleanup. >> >> >> [Alia] The risk that client B comes and changes the state after an Agent >> reboot justifies the RS cleanup of that state before?? Remember that Client >> A and B aren't supposed to be overwriting each other's data. We've defined >> that as an error case and that policy between the clients should prevent it. >> >>> >>> Plus, if the Client is subscribed to a pub-sub bus then it could >>> presumably learn about an Agent cold start via a published message. At >>> that point, the client could re-establish its state to the Agent. >> >> >> [Alia] Hmm, I know there was a draft discussed about pub-sub methods in >> general - but I don't think that we've really nailed down how pub-sub would >> work. Absent anything, I'd assume that the I2RS agent is whom the client >> registers with to get its notifications. Now, if we want to have a >> different system being a bus (with the scale implications there), that might >> be different - but I don't think we've really talked about that. So, my >> assumption is that the Agent provides the notifications to Clients that have >> registered - and when the Agent reboots, there are no Clients registered to >> get the notifications. If you have a different model (or different thoughts >> on what to do for the pub-sub), want to start that discussion (perhaps in a >> different thread)? > > > A pub-sub method makes a lot of sense here. It offloads reliability out of > the I2RS protocols and into the systems supporting client-agent > communications. > > 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 also think we need to consider that SDN enables a distributed control > plane, but IMO its necessary for I2RS to provide specific transport / format s/necessary/unnecessary/ > requirements for all the various latency cases. Giving SDN implementors the > ability to solve their specific needs via a standardized way to negotiate > capabilities seems to have much broader utility. > > In the same vein, I don't think we can just limit the information an I2RS > agent provides to traditional "routing sytem" control plane state. For > example, data plane state greatly impacts TE decisions. Someone may want to > get 3000+ interface stats off a box every 30ms in order to do very real-time > TE, and someone else may want that data to do billing. Let's enable both at > the same time. > > >> >> >>> >>> If the Client is not part of the bus, it could periodically connect to >>> the Agent and learn that it was rebooted via the protocol...yeah, this >>> sounds a bit like SNMP, but it seems reasonable to me. >> >> >> [Alia] It doesn't sound reasonable to me... at least not to avoid what >> should be an error condition. Can we discuss more? Do you have additional >> justification for the significant added complexity. > > > Given push and pull capabilities, having the agent push a notification that > initiates some kind of state synchronization on the client would be ideal. > Push capabilities have a lot of nice features beyond a heart-beat, but that > probably does deserve another thread. > > -Scott > > >> >> >> Regards, >> Alia >> >>> >>> >>> 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 >>> >>> >>> ---------------------------------------------------------------------------- >> >> > > > -- > There was never any more inception than there is now, > Nor any more youth or age than there is now, > And will never be any more perfection than there is now, > Nor any more heaven or hell than there is now. > -Walt Whitman -- There was never any more inception than there is now, Nor any more youth or age than there is now, And will never be any more perfection than there is now, Nor any more heaven or hell than there is now. -Walt Whitman From j.schoenwaelder@jacobs-university.de Sun Sep 15 07:12:02 2013 Return-Path: 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 5DAAA11E8123 for ; Sun, 15 Sep 2013 07:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.32 X-Spam-Level: X-Spam-Status: No, score=-102.32 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, 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 Bhc38QOYJ5d0 for ; Sun, 15 Sep 2013 07:11:57 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2DAFA11E811A for ; Sun, 15 Sep 2013 07:11:55 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4813E20A13; Sun, 15 Sep 2013 16:11:54 +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 p9mairPbTwMh; Sun, 15 Sep 2013 16:11:54 +0200 (CEST) Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B6FD4209DC; Sun, 15 Sep 2013 16:11:53 +0200 (CEST) Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id 229E52854C0A; Sun, 15 Sep 2013 16:11:45 +0200 (CEST) Date: Sun, 15 Sep 2013 16:11:45 +0200 From: Juergen Schoenwaelder To: Scott Whyte Message-ID: <20130915141145.GA66175@elstar.jacobs.jacobs-university.de> Mail-Followup-To: Scott Whyte , Alia Atlas , "i2rs@ietf.org" , Joe Marcus Clarke References: <5231D77A.9050807@cisco.com> <5231DC28.9060600@cisco.com> <5231E14E.5020605@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "i2rs@ietf.org" , Joe Marcus Clarke , Alia Atlas 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 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 14:12:02 -0000 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? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From swhyte@google.com Sun Sep 15 12:54:07 2013 Return-Path: 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 AEA8911E81B5 for ; Sun, 15 Sep 2013 12:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] 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 Fx6dkc3nMWeH for ; Sun, 15 Sep 2013 12:54:07 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 313BD11E81B4 for ; Sun, 15 Sep 2013 12:54:07 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id wp4so3047831obc.14 for ; Sun, 15 Sep 2013 12:54:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=pwbJKvc1I/7dZiLAuunVSh5EuYURr/gEMrSG0bNiM1A=; b=J7NXLBT7XjbQZ/N4fuF53Chn7df4goZNMnz6PiF/hy8UNHmzHKQ9Jhp5EKzfuDkPCB nrBFODPogB1HkvNtJwdprNX2FFjnMV0JMu4+rgUVwrm9SstZ+4EPp9ptk8M+Tm+e1fmk fjU5hmRZAWEKBtDzOr2lHaEq30Z2xK1ZWW2UkCZorYyVsepMojqJrEKkEOwtBvNlbIeB F3YcnT+weMN3vOw5UzFs6oXWtb5wpkIURFVkdhWSKwYk50PPP9/nGLLsMaMLXotrc3z9 YVHEE4AE4UqW3xAbyIH/2gH3vzSzV/K3l/gCOgpv+gjQXT5xqUONNv8FYjERSuIaKmcf 3N/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=pwbJKvc1I/7dZiLAuunVSh5EuYURr/gEMrSG0bNiM1A=; b=NyZCtNiOjsF+J3eFEQkWkBSRpahVZFzn4sfac+/KJnobhPSQ8LepQRjM2Z/S1ykTtH wxMeGCE/faMJvhl10vQV+gOy573lP3DnZPQ+tI0kB4RvG5SqYIyRUjUW0SwH6zqsWk7S U1oseOJSeDAI7aQ0ueebin3S2V+EiIMw39GIkD2K3dTMfQyzdGlgK6oSZYs+TvqKQxj2 2Gja/3kOAX6zkSi5YrbwOmwGnL/+VBjBtNLAefTSdiHAgqs6M+/iy3IXkim0kP/3//zA /aAwsWDON5suNMxnalhI9FmrSwadlCi/9G3w+P8p7RFn+/DP4zPEciABBOtcBpi2lRq+ UVRA== X-Gm-Message-State: ALoCoQnarz5zDJamU1HhCdqQbfHshWBJLxGl3teiXjF79nVKGjQHmXcElaJDNUVzbAV0bpIXAGtXRS1vbh3DqB5SjY3Xady3ZVR7R6OUHlsEQcOOfoKVX48VzsiGyPnZOskVkKU4sHogyP0IlTJbNsOpw9oKsgLv5oa0l2Ua2ri2ys3XDw+4704FW5kJab8R5f939ZKTdBJ9 MIME-Version: 1.0 X-Received: by 10.60.52.81 with SMTP id r17mr22955437oeo.3.1379274846651; Sun, 15 Sep 2013 12:54:06 -0700 (PDT) Received: by 10.182.226.230 with HTTP; Sun, 15 Sep 2013 12:54:06 -0700 (PDT) In-Reply-To: <20130915141145.GA66175@elstar.jacobs.jacobs-university.de> References: <5231D77A.9050807@cisco.com> <5231DC28.9060600@cisco.com> <5231E14E.5020605@cisco.com> <20130915141145.GA66175@elstar.jacobs.jacobs-university.de> Date: Sun, 15 Sep 2013 20:54:06 +0100 Message-ID: From: Scott Whyte To: Juergen Schoenwaelder , Scott Whyte , Alia Atlas , "i2rs@ietf.org" , Joe Marcus Clarke Content-Type: text/plain; charset=UTF-8 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 19:54:07 -0000 On Sun, Sep 15, 2013 at 3:11 PM, 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? A pub-sub broker is an intermediary commonly used in distributed software applications. I was responding to Alia's assertion client-agent communication is always direct; I don't think that will be true even for I2RS 1.0 deployments and assuming there will be intermediaries certainly affects the data model (in the RFC3444 sense). -Scott > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- There was never any more inception than there is now, Nor any more youth or age than there is now, And will never be any more perfection than there is now, Nor any more heaven or hell than there is now. -Walt Whitman From jmh@joelhalpern.com Sun Sep 15 13:34:33 2013 Return-Path: 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 A032411E81C8 for ; Sun, 15 Sep 2013 13:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.277 X-Spam-Level: X-Spam-Status: No, score=-102.277 tagged_above=-999 required=5 tests=[AWL=0.322, BAYES_00=-2.599, 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 cGa5tZ5N2lFR for ; Sun, 15 Sep 2013 13:34:27 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id C8B0311E81C6 for ; Sun, 15 Sep 2013 13:34:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 83BB822043F; Sun, 15 Sep 2013 13:34:27 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (c213-89-137-101.bredband.comhem.se [213.89.137.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id C765B1C0529; Sun, 15 Sep 2013 13:34:25 -0700 (PDT) Message-ID: <523619CF.7030900@joelhalpern.com> Date: Sun, 15 Sep 2013 16:34:23 -0400 From: "Joel M. Halpern" 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 References: <5231D77A.9050807@cisco.com> <5231DC28.9060600@cisco.com> <5231E14E.5020605@cisco.com> <20130915141145.GA66175@elstar.jacobs.jacobs-university.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "i2rs@ietf.org" , Joe Marcus Clarke , Juergen Schoenwaelder , Alia Atlas 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 20:34:33 -0000 The model that is described in the I2RS archtiecture currently does not talk about, assume, or use a pub-sub broker. The use of broker in the WG discussion has been about an I2RS client that is making requests on behalf of other entities. The protocol those entities use with the "broker" might be I2RS< or something else. I2RS itself does not care. The reason we care about these brokers is that they motive having two identities associated with a request, the client that sent the request and the originator of the request. Yours, Joel On 9/15/13 3:54 PM, Scott Whyte wrote: > On Sun, Sep 15, 2013 at 3:11 PM, 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? > > A pub-sub broker is an intermediary commonly used in distributed > software applications. I was responding to Alia's assertion > client-agent communication is always direct; I don't think that will > be true even for I2RS 1.0 deployments and assuming there will be > intermediaries certainly affects the data model (in the RFC3444 > sense). > > -Scott > >> >> /js >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 > > > From russw@riw.us Mon Sep 16 06:15:06 2013 Return-Path: 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 4E18411E824A for ; Mon, 16 Sep 2013 06:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] 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 UxOB-FcyW4Pq for ; Mon, 16 Sep 2013 06:15:00 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9A711E8247 for ; Mon, 16 Sep 2013 06:15:00 -0700 (PDT) Received: from cpe-098-122-147-095.nc.res.rr.com ([98.122.147.95] helo=RussPC) by da31.namelessnet.net with esmtpa (Exim 4.80.1) (envelope-from ) id 1VLYdm-0001We-Rt; Mon, 16 Sep 2013 06:14:59 -0700 From: "Russ White" To: "'Sriganesh Kini'" References: <42DC10E7-3A2A-4BCF-BD61-7C38134B7E37@riw.us> In-Reply-To: Date: Mon, 16 Sep 2013 09:15:04 -0400 Message-ID: <01a901ceb2de$c26780d0$47368270$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHQxj3nhi8xmZPzQG9OFcaQDWNheQHjZC0SAq9Vha6Zn5j4cA== Content-Language: en-us X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Cc: i2rs@ietf.org, 'Alia Atlas' Subject: Re: [i2rs] Architecture Discussion 4: templates for Policy and QoS mechanisms X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 13:15:06 -0000 > Characterizing every possible QoS model is practically impossible. Do = you > have any standard model in mind that would be suitable to use as a = base ? I was thinking about something around the diffserv work, possibly = RFC4594 figures 3 or 7, perhaps. We might get someone who was more = deeply involved in diffserv to give us a better model to work from. > I would also be interested in hearing feedback on PBR. The 5 tuple = based > classification seems to be the most basic. But additionally one could = use > other fields ethernet, MPLS, QoS bits, length, range etc to construct = the > classification policy. Similar issues for for rewriting packet header = fields. If > anyone has any specific model they would like to see please send = feedback > to the list (or the draft authors) with the supporting use-case. This actually goes to the definition of what "PBR" means. Are we = thinking more like an OpenFlow model, where the entire header is used to = switch, or are we thinking more like "traditional" PBR, where we just = add source information into the switch path? The difference would be = whether or not the QoS bits, for instance, are used to make a switching = determination. :-) Russ From edc@google.com Mon Sep 16 09:37:26 2013 Return-Path: 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 0992011E810E for ; Mon, 16 Sep 2013 09:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] 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 gj3VoKrQO64Q for ; Mon, 16 Sep 2013 09:37:25 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 079E111E8280 for ; Mon, 16 Sep 2013 09:37:24 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id cb5so3709062wib.9 for ; Mon, 16 Sep 2013 09:37:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=oaDvPHS+3M6XVqG/2PFsGwaoqN3Nla6J+JbGQ6J2Bhs=; b=o+k1uOn+s98V3nPQ7PVrfhdyGkElxyxz/SKMVjaS+Es/rbTwA40o4lUZIp346+bNLZ w0Lcunbr9u7o3mfIhVR9zXtT29QPymg+AnB/UxAC8QmclxhVw2ilUsRKTZMChycyHpsw wI8Q0b3AxUXTYGIbD5DCo/HWsZS/mMKHddPSoxeC9zBEUhjHWkztAPn76t2I4zjE7WmG 6pgjD1OqxN7BTRTBjqcV+mlbLRv55W7e/l3G28WLVqwIdq25Gepe4wng55A6+CELGn+F PcJtRdhbD6HGMbNpJcYl4A+rqToOurYuM+SvM7RUxt8YuROKD0C+nzuLSQ15kIeoYYoJ 11jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=oaDvPHS+3M6XVqG/2PFsGwaoqN3Nla6J+JbGQ6J2Bhs=; b=dHRl5hOeiRxCjKJGLbpSqgwEqdAV/DF3XKq7Z2IzpT6HezZYZOmiH3gWqWzMfRYfaN tol7pOH09doqg44ODZpUh4DshS9VFt4Z8/SiEHbuTGspUSIi/TArls3kAerzd7CNSD2B aHJP1f8qvfDknhpVQptc2XaERNqtzYm/8dtqEWHNr/6WOrfv/by76X0Neks7Q3JjqNzR kpvK9uyiHNtncx89w+cyNgAIbmQoCDK1JBkM7XegbUoiU0sl+RxZ/qXV4SLNU72TMG9G wnU2ZVffHo/YlSjncdl4psRnyWgvADccsvxms8+CQ7XkdcPrazqNCNZaQHG667rJMVRK CrtQ== X-Gm-Message-State: ALoCoQn5Pq6gYQM4wilHm/sr443c1iWhNh/P9kIbSKeSRXj19CfGYkb1cJRgeEMt0UTdFdKZk6FXCuxpQZZkORoY9M2oLiYvYQ5sgDRLlBPQW1GLL4Q0V7yd+H44CZBw5PGj/AfGGEVMjr3C1cAMWk1JN+j7L/QzWPXYhf5UcZsrr/ypROmCSyVyafZA9Sl+I/S6rm17R7PM X-Received: by 10.180.12.243 with SMTP id b19mr14094112wic.18.1379349443463; Mon, 16 Sep 2013 09:37:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.23.3 with HTTP; Mon, 16 Sep 2013 09:36:43 -0700 (PDT) In-Reply-To: References: From: Edward Crabbe Date: Mon, 16 Sep 2013 09:36:43 -0700 Message-ID: To: "i2rs@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 16:37:26 -0000 This call for WG adoption is completed. Support has clearly been demonstrated and draft-nitinb-i2rs-rib-info-model has now been adopted as a WG document. On Mon, Sep 9, 2013 at 7:28 PM, Luay Jalil wrote: > Support > > Luay > > > On Monday, August 26, 2013, Edward Crabbe wrote: >> >> Hey all; >> >> Nitin published an updated version of his RIB info model draft, available >> at: >> >> http://tools.ietf.org/html/draft-nitinb-i2rs-rib-info-model-02 >> >> Please review this draft and comment on whether it should be adopted >> as an I2RS document. >> >> This WG call for adoption will finish on September 9th. >> >> best, >> -ed >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs > > > > -- > Luay From akatlas@gmail.com Mon Sep 16 12:13:20 2013 Return-Path: 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 1833711E817D for ; Mon, 16 Sep 2013 12:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 b6GwkkGJ6lDe for ; Mon, 16 Sep 2013 12:13:19 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 12B9A11E8142 for ; Mon, 16 Sep 2013 12:13:18 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id ar20so8444137iec.32 for ; Mon, 16 Sep 2013 12:13:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KxqMtfu6GKQH8HJC+Z3LLhCu/sEKb+Zljfr32vUrbrg=; b=KOXbJNGZSeUaQcc6Pf9i/fJ5mj4Agez4bDW8h1RGZKY03eEN8+gAeMmcp0ZvXHCna8 +jL2U0ULV1WeG/un5E6+3zuavj4fmX0Yupke2cKv82idhww5tUVE8lV2ur5Z8kfC/XcQ Fd876vLm4P2A1Hc8Xe0QuScmOM0oECbnPU5k5XxnkxxH1NFUkmPaud/kIZe6LrBXzGsP JPLvYpkK/pBN+pGthzKhCrpYPrGtvU6s7qBzna9Z2OcoSTj0za+Zp8vhi1iZ7TuxTqro p7KpxSe059PPjjsDI4Au4OZcNMNocupKI6ZsRMrtcosNdTR5VuNlYBemirHFfqTgVgmq D7Kg== MIME-Version: 1.0 X-Received: by 10.50.128.137 with SMTP id no9mr6856370igb.36.1379358794979; Mon, 16 Sep 2013 12:13:14 -0700 (PDT) Received: by 10.64.13.145 with HTTP; Mon, 16 Sep 2013 12:13:14 -0700 (PDT) In-Reply-To: References: Date: Mon, 16 Sep 2013 15:13:14 -0400 Message-ID: From: Alia Atlas To: Edward Crabbe Content-Type: multipart/alternative; boundary=047d7b10cf0dfe21b804e684fe10 Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 19:13:20 -0000 --047d7b10cf0dfe21b804e684fe10 Content-Type: text/plain; charset=ISO-8859-1 Nitin and co-authors, Please do address Joel and Sue's comments in email and the next draft after you have submitted draft-ietf-i2rs-rib-info-model-00 which should be the same as the current draft-nitinb-i2rs-rib-info-model. Thanks, Alia On Mon, Sep 16, 2013 at 12:36 PM, Edward Crabbe wrote: > This call for WG adoption is completed. Support has clearly been > demonstrated and draft-nitinb-i2rs-rib-info-model has now been adopted > as a WG document. > > On Mon, Sep 9, 2013 at 7:28 PM, Luay Jalil wrote: > > Support > > > > Luay > > > > > > On Monday, August 26, 2013, Edward Crabbe wrote: > >> > >> Hey all; > >> > >> Nitin published an updated version of his RIB info model draft, > available > >> at: > >> > >> http://tools.ietf.org/html/draft-nitinb-i2rs-rib-info-model-02 > >> > >> Please review this draft and comment on whether it should be adopted > >> as an I2RS document. > >> > >> This WG call for adoption will finish on September 9th. > >> > >> best, > >> -ed > >> _______________________________________________ > >> i2rs mailing list > >> i2rs@ietf.org > >> https://www.ietf.org/mailman/listinfo/i2rs > > > > > > > > -- > > Luay > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --047d7b10cf0dfe21b804e684fe10 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Nitin and co-authors,

Please do address= Joel and Sue's comments in email and the next draft after you have sub= mitted draft-ietf-i2rs-rib-info-model-00 which should be the same as the cu= rrent draft-nitinb-i2rs-rib-info-model.

Thanks,
Alia


On Mon, Sep 16, 2013 at 12:36 PM, = Edward Crabbe <edc@google.com> wrote:
This call for WG adoption is completed. =A0S= upport has clearly been
demonstrated and draft-nitinb-i2rs-rib-info-model has now been adopted
as a WG document.

On Mon, Sep 9, 2013 at 7:28 PM, Luay Jalil <luayjalil@gmail.com> wrote:
> Support
>
> Luay
>
>
> On Monday, August 26, 2013, Edward Crabbe wrote:
>>
>> Hey all;
>>
>> Nitin published an updated version of his RIB info model draft, av= ailable
>> at:
>>
>> http://tools.ietf.org/html/draft-nitinb-i2rs-rib= -info-model-02
>>
>> Please review this draft and comment on whether it should be adopt= ed
>> as an I2RS document.
>>
>> This WG call for adoption will finish on September 9th.
>>
>> best,
>> =A0 =A0-ed
>> _______________________________________________
>> i2rs mailing list
>> i2rs@ietf.org
>> https://www.ietf.org/mailman/listinfo/i2rs
>
>
>
> --
> Luay
_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs

--047d7b10cf0dfe21b804e684fe10-- From internet-drafts@ietf.org Mon Sep 16 14:01:02 2013 Return-Path: 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 A5FD911E8328; Mon, 16 Sep 2013 14:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 dy-Py--HnJgW; Mon, 16 Sep 2013 14:01:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E197611E8270; Mon, 16 Sep 2013 14:00:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.71.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130916210051.20146.90791.idtracker@ietfa.amsl.com> Date: Mon, 16 Sep 2013 14:00:51 -0700 Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-rib-info-model-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 21:01:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Interface to the Routing System Working G= roup of the IETF. Title : Routing Information Base Info Model Author(s) : Nitin Bahadur Ron Folkes Sriganesh Kini Jan Medved Filename : draft-ietf-i2rs-rib-info-model-00.txt Pages : 26 Date : 2013-09-16 Abstract: Routing and routing functions in enterprise and carrier networks are typically performed by network devices (routers and switches) using a routing information base (RIB). Protocols and configuration push data into the RIB and the RIB manager install state into the hardware; for packet forwarding. This draft specifies an information model for the RIB to enable defining a standardized data model. Such a data model can be used to define an interface to the RIB from an entity that may even be external to the network device. This interface can be used to support new use-cases being defined by the IETF I2RS WG. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-info-model There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-i2rs-rib-info-model-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From sriganeshkini@gmail.com Tue Sep 17 11:20:56 2013 Return-Path: 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 4F4A811E8560 for ; Tue, 17 Sep 2013 11:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 iCCaBTQv48M3 for ; Tue, 17 Sep 2013 11:20:55 -0700 (PDT) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 9269111E855C for ; Tue, 17 Sep 2013 11:20:55 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id g10so5928385pdj.30 for ; Tue, 17 Sep 2013 11:20:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=re8XScc8QCNVx8uLKCmcRrH5SUygkZoCePFZ50aHIbY=; b=st40pHbsik+zMM5cAmzeaRdnj0/BiKoM9vR6GRebzBPoZJYnGV0uhrCTHAzwPUgbSA +N74rWjebAxhvPmpQqtPA2rIcUODUodjXX07pZrYePq+n4Crn4WV49Z4FjmliC2Qgg0V ONwQuXk8jP7W1SsNslyl2jBU0KJ0GvG2JGWXVF+vWn6v0Ldxgm724iGaH8B/8JkYvBXa kHyMx3zolBAToMuheX0tggpjWw8psv5KN+/CycUw8DKtSMVAJLXPOpRElw8GyccBS95g X7ajkZ3d85n4ND/fb3pyk5kj7FdM8h/lWPD48UaF1IPWXYZ28PPQlYZpLtsFLIZa6mPJ GtGw== X-Received: by 10.66.248.130 with SMTP id ym2mr4646420pac.177.1379442055175; Tue, 17 Sep 2013 11:20:55 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.70.13.129 with HTTP; Tue, 17 Sep 2013 11:20:24 -0700 (PDT) In-Reply-To: <01a901ceb2de$c26780d0$47368270$@riw.us> References: <42DC10E7-3A2A-4BCF-BD61-7C38134B7E37@riw.us> <01a901ceb2de$c26780d0$47368270$@riw.us> From: Sriganesh Kini Date: Tue, 17 Sep 2013 11:20:24 -0700 X-Google-Sender-Auth: ouE8LZfRQMGRwRmxq0N9VvagH9c Message-ID: To: Russ White Content-Type: multipart/alternative; boundary=047d7b2e15cdafe8d804e69861df Cc: "i2rs@ietf.org" , Alia Atlas Subject: Re: [i2rs] Architecture Discussion 4: templates for Policy and QoS mechanisms X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 18:20:56 -0000 --047d7b2e15cdafe8d804e69861df Content-Type: text/plain; charset=UTF-8 On Mon, Sep 16, 2013 at 6:15 AM, Russ White wrote: > > > Characterizing every possible QoS model is practically impossible. Do you > > have any standard model in mind that would be suitable to use as a base ? > > I was thinking about something around the diffserv work, possibly RFC4594 > figures 3 or 7, perhaps. We might get someone who was more deeply involved > in diffserv to give us a better model to work from. > Thanks. Will look into this. > > > I would also be interested in hearing feedback on PBR. The 5 tuple based > > classification seems to be the most basic. But additionally one could use > > other fields ethernet, MPLS, QoS bits, length, range etc to construct the > > classification policy. Similar issues for for rewriting packet header > fields. If > > anyone has any specific model they would like to see please send feedback > > to the list (or the draft authors) with the supporting use-case. > > This actually goes to the definition of what "PBR" means. Are we thinking > more like an OpenFlow model, where the entire header is used to switch, or > are we thinking more like "traditional" PBR, where we just add source > information into the switch path? The difference would be whether or not > the QoS bits, for instance, are used to make a switching determination. > We have started along the lines of traditional PBR that has been supported by routing-systems. We will look into other models only if there are strong use-cases and a desire in the WG to address them. > > :-) > > Russ > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > - Sri --047d7b2e15cdafe8d804e69861df Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Mon, Sep 16, 2013 at 6:15 AM, Russ White <<= a href=3D"mailto:russw@riw.us" target=3D"_blank">russw@riw.us> wrote:

> Characterizing every possible QoS model is practically impossible. Do = you
> have any standard model in mind that would be suitable to use as a bas= e ?

I was thinking about something around the diffserv work, possibly RFC= 4594 figures 3 or 7, perhaps. We might get someone who was more deeply invo= lved in diffserv to give us a better model to work from.

Thanks. Will look into this.
=C2=A0

> I would also be interested in hearing feedback on PBR. The 5 tuple bas= ed
> classification seems to be the most basic. But additionally one could = use
> other fields ethernet, MPLS, QoS bits, length, range etc to construct = the
> classification policy. Similar issues for for rewriting packet header = fields. If
> anyone has any specific model they would like to see please send feedb= ack
> to the list (or the draft authors) with the supporting use-case.

This actually goes to the definition of what "PBR" means. A= re we thinking more like an OpenFlow model, where the entire header is used= to switch, or are we thinking more like "traditional" PBR, where= we just add source information into the switch path? The difference would = be whether or not the QoS bits, for instance, are used to make a switching = determination.

We have started along the lines of traditi= onal PBR that has been supported by routing-systems. We will look into othe= r models only if there are strong use-cases and a desire in the WG to addre= ss them.
=C2=A0

:-)

Russ


_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs

- Sri
--047d7b2e15cdafe8d804e69861df-- From jclarke@cisco.com Tue Sep 17 12:28:42 2013 Return-Path: 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 ; 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 ; 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 ; 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 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 , Alia Atlas , "i2rs@ietf.org" References: <5231D77A.9050807@cisco.com> <5231DC28.9060600@cisco.com> <5231E14E.5020605@cisco.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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ---------------------------------------------------------------------------- From j.schoenwaelder@jacobs-university.de Tue Sep 17 12:51:48 2013 Return-Path: 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 ; 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 ; 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 ; 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 To: Joe Marcus Clarke Message-ID: <20130917195132.GA45071@elstar.local> Mail-Followup-To: Joe Marcus Clarke , Scott Whyte , Alia Atlas , "i2rs@ietf.org" References: <5231D77A.9050807@cisco.com> <5231DC28.9060600@cisco.com> <5231E14E.5020605@cisco.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" , Alia Atlas , Scott Whyte 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 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From tokatsu@cisco.com Tue Sep 17 21:29:15 2013 Return-Path: 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 3791511E80C5 for ; Tue, 17 Sep 2013 21:29:15 -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 NynmWG8vbSoW for ; Tue, 17 Sep 2013 21:29:10 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id EDD1021F8475 for ; Tue, 17 Sep 2013 21:29:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10166; q=dns/txt; s=iport; t=1379478550; x=1380688150; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=L72VND8+wDfBC3nN9xIpkFirTCTS+BxmvFMfRceSTVk=; b=JaQosv4nB3wTxErrli+Rq43RkR9cva7Xz5cNvgASQ4gy36OfELsvVFlA G6jIwL1iRkpDj39cLax6uEMvOh647oa8Auy4MyBBZC+jdS3cQU+oLsT6T gQ+LKpuTnQsKoWH+PxgnKsQpCzTBthn8R0pWO4NLFFDBkA1nDQKVn0x/s c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFALoqOVKtJXG8/2dsb2JhbABXA4MHOFLBN4EaFnSCJQEBAQMBAQEBJBMtBgEQBwICAgEIEQEDAQEBChQJBxsMCxQDBggCBAESCId1Bgy6GAQEjhqBGCEXBguDDYEAA6lvgySBcTk X-IronPort-AV: E=Sophos;i="4.90,928,1371081600"; d="scan'208";a="261176265" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 18 Sep 2013 04:29:05 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r8I4T5x0031837 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Sep 2013 04:29:05 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.33]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Tue, 17 Sep 2013 23:29:05 -0500 From: "Toru Okatsu (tokatsu)" To: "Joe Clarke (jclarke)" , Alia Atlas , "i2rs@ietf.org" Thread-Topic: [i2rs] Architecture Discussion 2: Persistence (ephemeral vs. permanent) Thread-Index: AQHOsWqQy8YDPQv4c0uYCBw4DVBW7JnK43XA Date: Wed, 18 Sep 2013 04:29:04 +0000 Message-ID: <2C754117643E1841B7DAA35BAC690E34086A5139@xmb-rcd-x10.cisco.com> References: <5231D77A.9050807@cisco.com> <5231DC28.9060600@cisco.com> <5231E14E.5020605@cisco.com> <5231FAD2.1060207@cisco.com> <52329B75.2080703@cisco.com> <523493CB.3000504@cisco.com> In-Reply-To: <523493CB.3000504@cisco.com> Accept-Language: en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.141.32.69] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 04:29:15 -0000 Hi Joe and Alia, I also think that if the agent has gone, information created by the agent i= n the RS should go away. It is like when the BGP process has gone, BGP routes should go away In terms of the notification of the agent availability, it depends on how f= ast it should be detected. Notification message from the agent to known client in Russ's idea would be= sent within less than 1 minute. This is because a crashed process is restarted within 1 minutes on most of = platforms. The heartbeat message like BGP keep alive would be useful to detect the fai= lure in more than 1 minutes. If any message is exchanged between the agent and the client, no heartbeat = is sent. If no message is exchanged for more than 5 minutes, a heartbeat message is = sent. This is for cases where the agent restart time is long or never. I don't think I2RS architecture have to cover all cases.=20 I don't think I2RS client should detect the failure of the agent in sub-sec= ond. By using HA technology like a hot-standby of the agent process, the possibi= lity of the agent crash would be mitigated. But I think it is out of scope of I2RS architecture.=20 Thanks, Toru > -----Original Message----- > From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of > Joe Clarke (jclarke) > Sent: Sunday, September 15, 2013 1:50 AM > To: Alia Atlas > Cc: i2rs@ietf.org > Subject: Re: [i2rs] Architecture Discussion 2: Persistence (ephemeral vs. > permanent) >=20 > On 9/13/13 10:57 AM, Alia Atlas wrote: > > Hi Joe, > > > > Summarizing up top (but leaving context) > > > > For a graceful Agent restart (i.e. not a crash), I think the behavior > > can be implementation-dependent. The implementation can either notify > > all Clients that have data written that the state is being > > preempted/torn down or it can just notify all Clients (that it knows > > of) that the Agent is going down. These are important notifications > > to capture in the I2RS Agent Info-Model. I don't think that either > > needs to be explicitly required as the only mode. I am certainly > > willing to be convinced otherwise. >=20 > I think I'm on the same page with you here. If the Agent is being gracef= ully > restarted, it flushes state, accepts no further connections, and notifies > all known Clients that state is being torn down. That works for me. >=20 > > > > For the case of an Agent crashing, I'm quite reluctant to create a > > heartbeat or persistent connection. This is a lot of complexity to ad= d > > for what should be a quite rare case. If the Agent crashes, leave the > > state and the Client will get an error when it tries to connect or > > otherwise request something. This does argue that on connection, the > > Client should get an indication of something like an Agent boot count > > /session id (and boot time). Russ's idea of storing known clients for > > the agent to connect to on reboot makes sense to me. >=20 > As I said in that other thread, I'm okay with the persistent list of Clie= nts. > I didn't think that would be more desirable that the heartbeat. However, > I think something needs to be done to notify Clients in case of a crash. > Else they might think everything is healthy when it's not. It might be > minutes, hours, days, never(?) before they reconnect to learn otherwise. >=20 > Joe >=20 > > > > I really dislike the idea of adding significant complexity to handle > > an edge failure case. > > > > Alia > > > > > > On Fri, Sep 13, 2013 at 12:58 AM, Joe Marcus Clarke > > wrote: > > > > On 9/12/13 3:49 PM, Alia Atlas wrote: > > > [Alia] But we (the WG) said that it was an error because we expec= t > > > coordination > > > between the applications to avoid multiple writers of the same da= ta. > > > It's not an > > > error because the Agent says so - the Agent would just report bac= k > > what > > > happened > > > (successful write or fail due to higher priority). > > > > My point was that the Agent knows the priority. This isn't passed > to > > the RS. > > > > > [Alia] As Joel had said, I think we're trying to avoid the need > for > > > persistent > > > connections just to confirm liveness. It's a heavy-handed way to > > do it. > > > That said, > > > we could use a mechanism to determine if the RS is up and if the > > associated > > > Agent is up. Of course, there can be multiple Agents per RS - ea= ch > > > supporting > > > different services or such. For a router reboot, a Client that is > > > learning topology > > > would hear very quickly that a router has failed or appeared. > > > > > > [Alia] So - developing a liveness detection mechanism is useful. > But > > > what would > > > be useful is the ability for the RS to notify interested clients > on a > > > failure. Otherwise, > > > what frequency would suffice for checking - when traffic can be > being > > > actively dropped > > > or misrouted if the Agent has failed. Also - are we designing > > for the > > > error-case of > > > a crashed Agent rather than the normal case of a gracefully shut > > down Agent? > > > > I was raising the point of both. In the graceful case, the Agent > clears > > all state and notifies all Clients. But the crash is a possibility= , > and > > we should stipulate what should happen to state. > > > > I don't think we want the RS doing anything to the Clients directly= . > I > > think perhaps an Agent->Client heartbeat is a useful thing if the > Client > > asks to be notified about changes. > > > > > > > > A third model I thought of was a broker model in which the Ag= ent > > > rebooting would be a broadcast event to all subscribers. > > > > > > > > > [Alia] I've been assuming, I guess, that Clients would hear about > > router > > > failures via > > > the topology DM based from the IGP. > > > > Router failure of Agent failure? > > > > > > > > > > > In either case, I saw that the Client would have some means > of > > knowing > > > the Agent went away. > > > > > > > > > [Alia] I can see that if the Client knew that the Agent went away > > > (ungracefully), that > > > having the associated RS clean up state would be fine. I haven't > yet > > > heard a fully baked > > > design where the client would know rapidly. We (you?) could come > up > > > with one, but > > > that needs to be written down and agreed to. Without that, I hea= r > > that > > > the Client's state > > > might suddenly disappear without the Client being able to tell - > > and am > > > much more comfortable > > > leaving it there to be removed either via CLI or to be read and > then > > > written again by the Client > > > when it reconnects. > > > > I've been kicking around the idea of a pub-sub "heartbeat." This > would > > give the Client awareness of the Agent's "thereness." If the > heartbeat > > carried a boot count, the Client might not need for multiple droppe= d > > heartbeats before reapplying state. I don't know if this is an ide= al > > way to confirm liveness of the agent, though I'm happy to propose > it > > more formally. I think the exact approach would depend on what the > > pub-sub mechanism is determined to be. > > > > > One other thing I haven't raised is the operator impact. How > > else could > > > an operator (i.e., owner/admin of a device) flush the I2RS > > changes? > > > There might be a malicious change or just some bad state, and > > they want > > > to clear that up. A restart of the Agent could do it without > > reloading > > > the device. > > > > > > > > > [Alia] Why wouldn't using the CLI to flush the I2RS changes work= ? > > > > It would. I didn't realize you were okay with a graceful restart > of the > > Agent purging all RS state for which it is responsible. If you are= , > > then that is handled. > > > > > Also, that > > > is a graceful restart of the Agent - where the Agent can tell eac= h > > > Client that all > > > its written data has been preempted because the Agent is > > rebooting. I'm > > > also > > > concerned that the behavior make sense for if/when the Agent fail= s. > I > > > could be > > > persuaded not to worry about that (Agents shouldn't crash) - but > I'd > > > prefer not to > > > mandate complexity for that case. > > > > I think we should. Because if there is a crash from the Agent, how > then > > can an admin purge state? There would no longer be a clean way to > do > > this. I'm trying to think what an operator might like here. > > > > 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 > > > > > > > ---------------------------------------------------------------------- > > ------ > > > > >=20 >=20 > -- > 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 >=20 > ---------------------------------------------------------------------- > ------ > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From jclarke@cisco.com Wed Sep 18 14:56:51 2013 Return-Path: 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 A566711E8263 for ; Wed, 18 Sep 2013 14:56:51 -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 Ib8beiO-nmsF for ; Wed, 18 Sep 2013 14:56:47 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id C1D3411E827E for ; Wed, 18 Sep 2013 14:56:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10836; q=dns/txt; s=iport; t=1379541406; x=1380751006; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=+UyDdFKsi4BEnO9LcxuWiSHIVkRywVIHybRJY1QFXgM=; b=a2X1AFMx+QQa5weL8OeVvAveVhpiTWjhMU0mc+u6obfSRUnMMhAjg3bM ZJIV7kixM1myBk4pxvetB5FbdSpnkNn8ynU+wrkicsjAg3pXiu2ZHHEMm zaiuR5kfJobmOInROIRmOpn2c7Sox5WYJvyGExMp/l5QagC4OIgwm3Djv s=; X-IronPort-AV: E=Sophos;i="4.90,931,1371081600"; d="scan'208";a="261616405" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 18 Sep 2013 21:56:46 +0000 Received: from dhcp-10-150-55-67.cisco.com (dhcp-10-150-55-67.cisco.com [10.150.55.67]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r8ILukQD011591; Wed, 18 Sep 2013 21:56:46 GMT Message-ID: <523A219D.2090401@cisco.com> Date: Wed, 18 Sep 2013 17:56:45 -0400 From: Joe Marcus Clarke 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: "Toru Okatsu (tokatsu)" References: <5231D77A.9050807@cisco.com> <5231DC28.9060600@cisco.com> <5231E14E.5020605@cisco.com> <5231FAD2.1060207@cisco.com> <52329B75.2080703@cisco.com> <523493CB.3000504@cisco.com> <2C754117643E1841B7DAA35BAC690E34086A5139@xmb-rcd-x10.cisco.com> In-Reply-To: <2C754117643E1841B7DAA35BAC690E34086A5139@xmb-rcd-x10.cisco.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "i2rs@ietf.org" , Alia Atlas 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 21:56:51 -0000 On 9/18/13 12:29 AM, Toru Okatsu (tokatsu) wrote: > Hi Joe and Alia, > > I also think that if the agent has gone, information created by the agent in the RS should go away. > It is like when the BGP process has gone, BGP routes should go away > > In terms of the notification of the agent availability, it depends on how fast it should be detected. > > Notification message from the agent to known client in Russ's idea would be sent within less than 1 minute. > This is because a crashed process is restarted within 1 minutes on most of platforms. Russ' idea could potentially recover as fast as the Agent can recover. The moment the Agent comes back, it notifies all previously subscribed Clients. > > The heartbeat message like BGP keep alive would be useful to detect the failure in more than 1 minutes. > If any message is exchanged between the agent and the client, no heartbeat is sent. > If no message is exchanged for more than 5 minutes, a heartbeat message is sent. > This is for cases where the agent restart time is long or never. > > I don't think I2RS architecture have to cover all cases. Agreed. However, Agent clean restart and Agent crash are two common scenarios I think are worth handling. Joe > I don't think I2RS client should detect the failure of the agent in sub-second. > By using HA technology like a hot-standby of the agent process, the possibility of the agent crash would be mitigated. > But I think it is out of scope of I2RS architecture. > > Thanks, > > Toru >> -----Original Message----- >> From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of >> Joe Clarke (jclarke) >> Sent: Sunday, September 15, 2013 1:50 AM >> To: Alia Atlas >> Cc: i2rs@ietf.org >> Subject: Re: [i2rs] Architecture Discussion 2: Persistence (ephemeral vs. >> permanent) >> >> On 9/13/13 10:57 AM, Alia Atlas wrote: >>> Hi Joe, >>> >>> Summarizing up top (but leaving context) >>> >>> For a graceful Agent restart (i.e. not a crash), I think the behavior >>> can be implementation-dependent. The implementation can either notify >>> all Clients that have data written that the state is being >>> preempted/torn down or it can just notify all Clients (that it knows >>> of) that the Agent is going down. These are important notifications >>> to capture in the I2RS Agent Info-Model. I don't think that either >>> needs to be explicitly required as the only mode. I am certainly >>> willing to be convinced otherwise. >> >> I think I'm on the same page with you here. If the Agent is being gracefully >> restarted, it flushes state, accepts no further connections, and notifies >> all known Clients that state is being torn down. That works for me. >> >>> >>> For the case of an Agent crashing, I'm quite reluctant to create a >>> heartbeat or persistent connection. This is a lot of complexity to add >>> for what should be a quite rare case. If the Agent crashes, leave the >>> state and the Client will get an error when it tries to connect or >>> otherwise request something. This does argue that on connection, the >>> Client should get an indication of something like an Agent boot count >>> /session id (and boot time). Russ's idea of storing known clients for >>> the agent to connect to on reboot makes sense to me. >> >> As I said in that other thread, I'm okay with the persistent list of Clients. >> I didn't think that would be more desirable that the heartbeat. However, >> I think something needs to be done to notify Clients in case of a crash. >> Else they might think everything is healthy when it's not. It might be >> minutes, hours, days, never(?) before they reconnect to learn otherwise. >> >> Joe >> >>> >>> I really dislike the idea of adding significant complexity to handle >>> an edge failure case. >>> >>> Alia >>> >>> >>> On Fri, Sep 13, 2013 at 12:58 AM, Joe Marcus Clarke >> > wrote: >>> >>> On 9/12/13 3:49 PM, Alia Atlas wrote: >>> > [Alia] But we (the WG) said that it was an error because we expect >>> > coordination >>> > between the applications to avoid multiple writers of the same data. >>> > It's not an >>> > error because the Agent says so - the Agent would just report back >>> what >>> > happened >>> > (successful write or fail due to higher priority). >>> >>> My point was that the Agent knows the priority. This isn't passed >> to >>> the RS. >>> >>> > [Alia] As Joel had said, I think we're trying to avoid the need >> for >>> > persistent >>> > connections just to confirm liveness. It's a heavy-handed way to >>> do it. >>> > That said, >>> > we could use a mechanism to determine if the RS is up and if the >>> associated >>> > Agent is up. Of course, there can be multiple Agents per RS - each >>> > supporting >>> > different services or such. For a router reboot, a Client that is >>> > learning topology >>> > would hear very quickly that a router has failed or appeared. >>> > >>> > [Alia] So - developing a liveness detection mechanism is useful. >> But >>> > what would >>> > be useful is the ability for the RS to notify interested clients >> on a >>> > failure. Otherwise, >>> > what frequency would suffice for checking - when traffic can be >> being >>> > actively dropped >>> > or misrouted if the Agent has failed. Also - are we designing >>> for the >>> > error-case of >>> > a crashed Agent rather than the normal case of a gracefully shut >>> down Agent? >>> >>> I was raising the point of both. In the graceful case, the Agent >> clears >>> all state and notifies all Clients. But the crash is a possibility, >> and >>> we should stipulate what should happen to state. >>> >>> I don't think we want the RS doing anything to the Clients directly. >> I >>> think perhaps an Agent->Client heartbeat is a useful thing if the >> Client >>> asks to be notified about changes. >>> >>> > >>> > A third model I thought of was a broker model in which the Agent >>> > rebooting would be a broadcast event to all subscribers. >>> > >>> > >>> > [Alia] I've been assuming, I guess, that Clients would hear about >>> router >>> > failures via >>> > the topology DM based from the IGP. >>> >>> Router failure of Agent failure? >>> >>> > >>> > >>> > In either case, I saw that the Client would have some means >> of >>> knowing >>> > the Agent went away. >>> > >>> > >>> > [Alia] I can see that if the Client knew that the Agent went away >>> > (ungracefully), that >>> > having the associated RS clean up state would be fine. I haven't >> yet >>> > heard a fully baked >>> > design where the client would know rapidly. We (you?) could come >> up >>> > with one, but >>> > that needs to be written down and agreed to. Without that, I hear >>> that >>> > the Client's state >>> > might suddenly disappear without the Client being able to tell - >>> and am >>> > much more comfortable >>> > leaving it there to be removed either via CLI or to be read and >> then >>> > written again by the Client >>> > when it reconnects. >>> >>> I've been kicking around the idea of a pub-sub "heartbeat." This >> would >>> give the Client awareness of the Agent's "thereness." If the >> heartbeat >>> carried a boot count, the Client might not need for multiple dropped >>> heartbeats before reapplying state. I don't know if this is an ideal >>> way to confirm liveness of the agent, though I'm happy to propose >> it >>> more formally. I think the exact approach would depend on what the >>> pub-sub mechanism is determined to be. >>> >>> > One other thing I haven't raised is the operator impact. How >>> else could >>> > an operator (i.e., owner/admin of a device) flush the I2RS >>> changes? >>> > There might be a malicious change or just some bad state, and >>> they want >>> > to clear that up. A restart of the Agent could do it without >>> reloading >>> > the device. >>> > >>> > >>> > [Alia] Why wouldn't using the CLI to flush the I2RS changes work? >>> >>> It would. I didn't realize you were okay with a graceful restart >> of the >>> Agent purging all RS state for which it is responsible. If you are, >>> then that is handled. >>> >>> > Also, that >>> > is a graceful restart of the Agent - where the Agent can tell each >>> > Client that all >>> > its written data has been preempted because the Agent is >>> rebooting. I'm >>> > also >>> > concerned that the behavior make sense for if/when the Agent fails. >> I >>> > could be >>> > persuaded not to worry about that (Agents shouldn't crash) - but >> I'd >>> > prefer not to >>> > mandate complexity for that case. >>> >>> I think we should. Because if there is a crash from the Agent, how >> then >>> can an admin purge state? There would no longer be a clean way to >> do >>> this. I'm trying to think what an operator might like here. >>> >>> 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 >>> >>> >>> >> ---------------------------------------------------------------------- >>> ------ >>> >>> >> >> >> -- >> 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 >> >> ---------------------------------------------------------------------- >> ------ >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs -- 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 ---------------------------------------------------------------------------- From nabil.n.bitar@verizon.com Thu Sep 26 07:17:20 2013 Return-Path: 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 D9F6011E8109 for ; Thu, 26 Sep 2013 07:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 7G0KZp51Npay for ; Thu, 26 Sep 2013 07:17:02 -0700 (PDT) Received: from fldsmtpe03.verizon.com (fldsmtpe03.verizon.com [140.108.26.142]) by ietfa.amsl.com (Postfix) with ESMTP id 8917811E8103 for ; Thu, 26 Sep 2013 07:17:01 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by fldsmtpe03.verizon.com with ESMTP; 26 Sep 2013 14:16:57 +0000 From: "Bitar, Nabil N" X-IronPort-AV: E=Sophos;i="4.90,986,1371081600"; d="scan'208,217";a="566727122" Received: from fldp1lumxc7hb03.verizon.com (HELO FLDP1LUMXC7HB03.us.one.verizon.com) ([166.68.75.86]) by fldsmtpi01.verizon.com with ESMTP; 26 Sep 2013 14:16:12 +0000 Received: from fldp1lumxc7v63.us.one.verizon.com ([166.68.45.45]) by FLDP1LUMXC7HB03.us.one.verizon.com ([166.68.75.86]) with mapi; Thu, 26 Sep 2013 10:16:12 -0400 To: "i2rs@ietf.org" Date: Thu, 26 Sep 2013 10:16:11 -0400 Thread-Topic: soliciting WG feedback and comments on draft-bitar-i2rs-service-chaining-00 Thread-Index: Ac66wvP5iN29Tr91QYKGilSjp8es2w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CE69901DC72DEnabilnbitarverizoncom_" MIME-Version: 1.0 Subject: [i2rs] soliciting WG feedback and comments on draft-bitar-i2rs-service-chaining-00 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 14:17:21 -0000 --_000_CE69901DC72DEnabilnbitarverizoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We had submitted the following draft http://tools.ietf.org/html/draft-bitar= -i2rs-service-chaining-00 last ietf. Your feedback and comments on the i2rs= mailing list are appreciated. We will be looking to update the draft. Thanks, Nabil --_000_CE69901DC72DEnabilnbitarverizoncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
We had sub= mitted the following draft http://tools.ietf.org/html/draft-bitar-i2r= s-service-chaining-00 last ietf. Your feedback and comments on the= i2rs mailing list are appreciated. We will be looking to update the draft.=


Thanks,
Nabil
=
--_000_CE69901DC72DEnabilnbitarverizoncom_-- From c.vijaya.durga@gmail.com Wed Sep 25 23:51:09 2013 Return-Path: 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 974D211E815F for ; Wed, 25 Sep 2013 23:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 pSYGVPUN18E4 for ; Wed, 25 Sep 2013 23:51:06 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 7048C11E8162 for ; Wed, 25 Sep 2013 23:51:02 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id ep20so592358lab.1 for ; Wed, 25 Sep 2013 23:51:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=uy+3+iT52B6jSBxe95rjf7i3Xo/MylDXoMmgqF/OJZc=; b=vPFPQbYvCnS16JGH1afVU5Fj0hn31SltB/0sv8zdmvmwcS64844wqRxCJKAbAgnwLd eEUJxdJKHDlkh9Iy+3dYfUl2aG1UOW8WT2M/C7801Vb+P/uIXo3pULWzyk7GImR3N64V hh7GR8V8hUHU8H3vgdQNI9PwIST48o7eloFT0p91MgibApaBIOkxL+kPjlRH361Kb9oK Jw4bVg5wwk8z2QzLnqHgyXRf/HnO5J7M/9+C6QqQBNTDzWMw5f8/FYkF4gdR3LSOqjCk +uaI0zuwMqRGEWmD+6+BxwyYyUPN/J8u4tsTzjLs0ysLqLTrqjZI2U0WMnF/vAoj7EMJ BRJw== X-Received: by 10.112.161.105 with SMTP id xr9mr154194lbb.40.1380178261287; Wed, 25 Sep 2013 23:51:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.215.36 with HTTP; Wed, 25 Sep 2013 23:50:41 -0700 (PDT) From: durga Date: Thu, 26 Sep 2013 16:50:41 +1000 Message-ID: To: i2rs@ietf.org Content-Type: multipart/alternative; boundary=001a11c37d64fda8ad04e743ca9b X-Mailman-Approved-At: Thu, 26 Sep 2013 07:53:28 -0700 Subject: [i2rs] query regarding i2rs :resources X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 06:52:31 -0000 --001a11c37d64fda8ad04e743ca9b Content-Type: text/plain; charset=ISO-8859-1 Hi all, this is durga and I am trying to understand how traditional routing mechanisms would fit in SDN framework and came across I2RS. Just wondering if i2RS still under active prototyping or development??? Cheers! Durga --001a11c37d64fda8ad04e743ca9b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi all,

=A0this is durga and I am trying to understand how traditional routing mech= anisms would fit in SDN framework and came across I2RS. Just wondering if i= 2RS still under active prototyping or development???=A0


Cheers!
Durga

--001a11c37d64fda8ad04e743ca9b-- From jclarke@cisco.com Sat Sep 28 17:08:23 2013 Return-Path: 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 6B5C721E8082 for ; Sat, 28 Sep 2013 17:08:23 -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 jKudn0wp5vNA for ; Sat, 28 Sep 2013 17:08:18 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 6E84F21E812F for ; Sat, 28 Sep 2013 17:08:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2428; q=dns/txt; s=iport; t=1380413296; x=1381622896; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=EtnZHU6a47D0YmaI3j4bhYYvbrJNyQQ85zIHrQ6ctDM=; b=cNjd0jFmbllbiaQk8bNeK4UQig9fdmWgPEPFfbCCck4TGchK+lBZokrA D400Zbt9L1J6FH/iXRE8sJ05gpbAQauuL2Fcr2K1JEN22gybdO0U03+nT ImzWraezpZve7AO5TJxy932PymJRAp4pFFEHJp+ngJOY3uq4X35RcoFjp 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoIFAD5uR1KtJXG+/2dsb2JhbABWA4MHOIN7vUiBIRZtB4IlAQEBBCMVPwENAgIcAQIBAgMCBRYLAgIJAwIBAgEJLgQCCAYNBgIBAQWHfQyoTJF5BIEljF+BJxIXBguCWYE4A5d/gS+QSoNAIIE1 X-IronPort-AV: E=Sophos;i="4.90,1001,1371081600"; d="scan'208";a="265768781" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 29 Sep 2013 00:08:16 +0000 Received: from rtp-vpn4-1056.cisco.com (rtp-vpn4-1056.cisco.com [10.82.212.32]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r8T08F93022267 for ; Sun, 29 Sep 2013 00:08:15 GMT Message-ID: <52476F71.5080608@cisco.com> Date: Sat, 28 Sep 2013 20:08:17 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: "i2rs@ietf.org" References: <20130929000501.9951.55365.idtracker@ietfa.amsl.com> In-Reply-To: <20130929000501.9951.55365.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130929000501.9951.55365.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [i2rs] Fwd: New Version Notification for draft-clarke-i2rs-traceability-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Sep 2013 00:08:23 -0000 This is an answer to the suggestion by Alia for a document describing aspects of I2RS traceability. Some of the ideas in this document are suggestions on how the overall I2RS protocol might be designed while at the same time knowing that changes will need to be made as the protocol evolves. Joe -------- Original Message -------- Subject: New Version Notification for draft-clarke-i2rs-traceability-00.txt Date: Sat, 28 Sep 2013 17:05:01 -0700 From: To: Joe Clarke , Gonzalo Salgueiro , Carlos Pignataro A new version of I-D, draft-clarke-i2rs-traceability-00.txt has been successfully submitted by Joe Clarke and posted to the IETF repository. Filename: draft-clarke-i2rs-traceability Revision: 00 Title: Interface to the Routing System (I2RS) Traceability: Framework and Information Model Creation date: 2013-09-28 Group: Individual Submission Number of pages: 12 URL: http://www.ietf.org/internet-drafts/draft-clarke-i2rs-traceability-00.txt Status: http://datatracker.ietf.org/doc/draft-clarke-i2rs-traceability Htmlized: http://tools.ietf.org/html/draft-clarke-i2rs-traceability-00 Abstract: This document describes a framework for traceability in the Interface to the Routing System (I2RS) and information model for that framework. It specifies the motivation, requirements, use cases, and defines an information model for recording interactions between elements implementing the I2RS protocol. This framework provides a consistent tracing interface for components implementing the I2RS architecture to record what was done, by which component, and when. It aims to improve the management of I2RS implementations, and can be used for troubleshooting, auditing, forensics, and accounting purposes. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- 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 ----------------------------------------------------------------------------