Re: [irs-discuss] IRS Problem Statement Posted

Alia Atlas <> Tue, 31 July 2012 02:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8FD3011E80CC for <>; Mon, 30 Jul 2012 19:22:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wdpIHWeDmy3J for <>; Mon, 30 Jul 2012 19:22:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1051E11E809A for <>; Mon, 30 Jul 2012 19:22:54 -0700 (PDT)
Received: by yenq13 with SMTP id q13so6018184yen.31 for <>; Mon, 30 Jul 2012 19:22:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=GleVUhe6Xqmc3tPtYA++iJO/Jf4DnMYkMCk/0vlED74=; b=XPb0IULm01FJE++pEFpoOWcJbmTSfgSZ01qCrQTeVPWk7lEctk5uBtDlcsI4Or9obx 98YBBegELeilkCB5nmZPLHTzwa0HCRSsBnItPTN8WUQMzqWL+hWH7N9NdIqdiPgE1F7V PqidmYv0HF2T6KA8cf4TrZtRUBiXh1YHzz59KMoNmZ33uw55q9DXS8I3F3CZtTIvegY0 qgGYYTouo2sjwBu8GIg8TAzmkBhK/AWrlAIlZuyN6r/71lYc6nhUXZSPVeeRVAD/SZxh KmGxm37m3362d5kVwTGeEWF7LnsZpYc2951tndL7P6zDERN8YFAFLMN8qIK2w/JO+M3F 8MWw==
MIME-Version: 1.0
Received: by with SMTP id no1mr544021igc.71.1343701372831; Mon, 30 Jul 2012 19:22:52 -0700 (PDT)
Received: by with HTTP; Mon, 30 Jul 2012 19:22:52 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
Date: Mon, 30 Jul 2012 22:22:52 -0400
Message-ID: <>
From: Alia Atlas <>
To: Robert Raszuk <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Thomas Nadeau <>, Nitin Bahadur <>, Susan Hares <>, James Kempf <>, "" <>
Subject: Re: [irs-discuss] IRS Problem Statement Posted
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, 31 Jul 2012 02:22:57 -0000


I have also been following Openflow - granted primarily on the hybrid
and futures areas.  Yes, Openflow allows specification of flow-based
forwarding - which can apply to /32 IPv4 routes.

This list is NOT to discuss OpenFlow nor to focus on what it does or
can be contorted to do.  Are overlaps of interest?  Yes - but you are
not usefully describing that.

On Mon, Jul 30, 2012 at 10:09 PM, Robert Raszuk <>; wrote:
> Alia,
>> Hi Rob,
>> On the lower layer, Openflow talks to control/specify the forwarding
>> plane - heading towards forwarding plane modeling; something that
>> ForCES did a while ago.  It focuses on Layer-2 and does not interact
>> with the routing control plane - generally assuming that the routing
>> control protocol does not/should not exist.
> Completely incorrect assumption sorry. OF does not assume L2 as an example I have been working on routing applications over OF based data plane for over a year now.

[Alia] OF requires LLDP to learn the topology!  Yes, there is
flow-based policy-based forwarding - for host-routes.

> OF separates control plane including ability to run routing protocols from forwarding entities. That's the most important point.

[Alia] And NOT  what IRS is doing.

> Hybrid work actually does not help too much .. Especially the integrated effort. Retrieving state is not a focus as the assumption is that such state is known in the controller. However state validation or verification is something that OF need to pay more attention to - no question.

[Alia] Right - Openflow assumes one controller for a switch.  IRS does
not.   I am NOT trying to suggest/guide OpenFlow here - that is what
the ONF is for.

> Btw .. If IETF magically does something to equipment vendors so they will ship FORCEs enabled platforms I am all game. That would be productive. IRS as of now is more to mud the water then to come with an alternative to Forces or OF.

[Alia] IRS is providing control strings to different layers in the
routing system.   It is not doing the same thing as ForCES or
Openflow.   I am sorry that you feel that proposing something
different is muddying the water.


> Best regards,
> R.
>> Yes, there is nascent
>> work on hybrid OpenFlow switches - but that is very far from a model
>> based on USING the router's OS and routing capabilities and handling
>> multiple applications installing state.   Retrieving state is also not
>> a focus in Openflow.
>> On the upper layer, ONF is starting to tentatively talk about
>> northbound APIs - which are from OpenFlow controllers up towards
>> orchestrators or applications.
>> I  don't, personally, think that IRS should cover the latter upper
>> layer - though a translation layer and thinking through the network OS
>> abstractions is certainly interesting and part of the ecosystem.
>> Would you care to clearly clarify your concerns and assumptions about
>> intentions?
>> The two drafts work at defining what IRS should be; I think that there
>> is a clear difference in approach and intended functionality from
>> OpenFlow.
>> Surely you aren't suggesting that the IETF should not do anything in
>> this space because OpenFlow might get around to it someday?
>> Alia
>> On Mon, Jul 30, 2012 at 9:48 PM, Robert Raszuk <>; wrote:
>>> hi Nitin,
>>>> So IRS needs to define interfaces for both the lower layer and the upper layer.
>>> That's precisely what openflow protocol does. Thx for confirming clearly the intentions ;).
>>> Best regards,
>>> R.
>>> _______________________________________________
>>> irs-discuss mailing list
>> _______________________________________________
>> irs-discuss mailing list