Re: [irs-discuss] IRS Problem Statement Posted

Thomas Nadeau <tnadeau@juniper.net> Tue, 31 July 2012 16:32 UTC

Return-Path: <tnadeau@juniper.net>
X-Original-To: irs-discuss@ietfa.amsl.com
Delivered-To: irs-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 762B721F8615 for <irs-discuss@ietfa.amsl.com>; Tue, 31 Jul 2012 09:32:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.405
X-Spam-Level:
X-Spam-Status: No, score=-6.405 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 gdgC1x6NGPrv for <irs-discuss@ietfa.amsl.com>; Tue, 31 Jul 2012 09:32:18 -0700 (PDT)
Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id CC2D821F860B for <irs-discuss@ietf.org>; Tue, 31 Jul 2012 09:32:17 -0700 (PDT)
Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUBgIkCpGrnOLiBBTC/m8GlEa0czMRUzK@postini.com; Tue, 31 Jul 2012 09:32:17 PDT
Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 31 Jul 2012 09:26:06 -0700
Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 31 Jul 2012 09:26:04 -0700
Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Tue, 31 Jul 2012 12:25:46 -0400
From: Thomas Nadeau <tnadeau@juniper.net>
To: "robert@raszuk.net" <robert@raszuk.net>, "irs-discuss@ietf.org" <irs-discuss@ietf.org>
Date: Tue, 31 Jul 2012 12:25:46 -0400
Thread-Topic: [irs-discuss] IRS Problem Statement Posted
Thread-Index: Ac1vOSOevvKerhxBRmWJOFJOwe0kug==
Message-ID: <CC3D5431.2A08%tnadeau@juniper.net>
In-Reply-To: <501804E4.7050705@raszuk.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.3.120616
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [irs-discuss] IRS Problem Statement Posted
X-BeenThere: irs-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <irs-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/irs-discuss>, <mailto:irs-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/irs-discuss>
List-Post: <mailto:irs-discuss@ietf.org>
List-Help: <mailto:irs-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/irs-discuss>, <mailto:irs-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Jul 2012 16:32:18 -0000

On 7/31/12 9:16 AM, "Robert Raszuk" <robert@raszuk.net> wrote:

>Jim,
>
>> IMO the ability to manipulate routing state, context, etc... is what IRS
> > brings to the table and this capability is needed..
>>
>> Jim Uttaro
>
>Manipulating routing state from outside of routing protocols seems to me
>like tampering with jet engines during the flight.

	Network operators modify the routing system while it is in flight all
the time using other interfaces, so I fail to see why this is so alarming.


>Alia,
>
>There is no point to keep arguing about IRS framework .. it can call to
>address world hunger or propose to turn Sahara into rain forest.
>I think we need to wait and see actual protocol(s) proposals which
>write/stream into current routing systems as opposed to industry
>alternatives which target to write to forwarding layer directly or use
>already proposed IETF tools like NETCONF which already provide a very
>good provisioning abstraction today.
>
>My observation is that IRS is yet one more attempt to wave the SDN
>banner in the IETF without much substance behind it.

	We would appreciate keeping the discussion focused on whether or not this
is a good problem to solve, and identifying that clearly. We are not
interested in 
pontifications about the IETF, its management or policies on this list. 8)

	Thanks,

	--Tom