Re: [irs-discuss] IRS Problem Statement Posted

"UTTARO, JAMES" <ju1738@att.com> Tue, 31 July 2012 14:10 UTC

Return-Path: <ju1738@att.com>
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 7A4ED21F8668 for <irs-discuss@ietfa.amsl.com>; Tue, 31 Jul 2012 07:10:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.427
X-Spam-Level:
X-Spam-Status: No, score=-106.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 5iqYyWxh1vR5 for <irs-discuss@ietfa.amsl.com>; Tue, 31 Jul 2012 07:10:25 -0700 (PDT)
Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id D464021F84F2 for <irs-discuss@ietf.org>; Tue, 31 Jul 2012 07:10:24 -0700 (PDT)
Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id 057e7105.2aaafc853940.509630.00-594.1388767.nbfkord-smmo05.seg.att.com (envelope-from <ju1738@att.com>); Tue, 31 Jul 2012 14:10:24 +0000 (UTC)
X-MXL-Hash: 5017e75043cf6983-30baf9a5f742d60cc5740346a2b33b59c4000cc7
Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id d47e7105.0.509611.00-399.1388697.nbfkord-smmo05.seg.att.com (envelope-from <ju1738@att.com>); Tue, 31 Jul 2012 14:10:22 +0000 (UTC)
X-MXL-Hash: 5017e74e1c335dd9-2944c89bd3f8a190331d0bf68bd642d1d43f62fb
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q6VEALFo015706; Tue, 31 Jul 2012 10:10:21 -0400
Received: from sflint02.pst.cso.att.com (sflint02.pst.cso.att.com [144.154.234.229]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q6VEAJnU015670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Jul 2012 10:10:20 -0400
Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (misout7msghub9e.itservices.sbc.com [144.151.223.61]) by sflint02.pst.cso.att.com (RSA Interceptor); Tue, 31 Jul 2012 10:10:07 -0400
Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.02.0298.004; Tue, 31 Jul 2012 10:10:07 -0400
From: "UTTARO, JAMES" <ju1738@att.com>
To: "'Alia Atlas'" <akatlas@gmail.com>, Robert Raszuk <robert@raszuk.net>
Thread-Topic: [irs-discuss] IRS Problem Statement Posted
Thread-Index: Ac1uf6vUr0RoAYPERve+GHr5XPQ6JgAIAMEAAADmuywABbPeIAAJLQWAAABQUQAAAFnagAAAYlmAAAB6owAAF9JzAAAHlYZA
Date: Tue, 31 Jul 2012 14:10:06 +0000
Message-ID: <B17A6910EEDD1F45980687268941550FB5C30F@MISOUT7MSGUSR9I.ITServices.sbc.com>
References: <CE39F5249064D946AA3535E63A014619656FB98703@EUSAACMS0703.eamcs.ericsson.se> <CC3C59B2.2275E%nitinb@juniper.net> <728F9B956B2C48439CA9294B1723B14623754A18@dfweml509-mbs.china.huawei.com> <EE2E7697-92F1-4E98-A3FE-47CDF28C81C7@juniper.net> <F0ABFF98-0B62-4203-B3BA-EF704AE0FBA7@raszuk.net> <CAG4d1rd-g5m6aUb6GQjvu++y6QjHrF1dgsdV7oePMSZaaaomeQ@mail.gmail.com> <CDE9865E-E8DE-4754-A0C2-8875ECCAF865@raszuk.net> <CAG4d1rcL7ttJctimrQEvxaV7L=3QZSCvfTaX43YFyTJF0nYBzA@mail.gmail.com> <CAG4d1redZy7=C2asceFYZsZoVsYh_XMLx5+GfxRio76t-97vHg@mail.gmail.com>
In-Reply-To: <CAG4d1redZy7=C2asceFYZsZoVsYh_XMLx5+GfxRio76t-97vHg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.91.76.182]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: <ju1738@att.com>
X-SOURCE-IP: [144.160.20.145]
X-AnalysisOut: [v=1.0 c=1 a=g8Qva45Ca7EA:10 a=N8_Zyk_AHbsA:10 a=ofMgfj31e3]
X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=ZRNLZ4dFUbCvG8]
X-AnalysisOut: [UMqPvVAA==:17 a=48vgC7mUAAAA:8 a=pGLkceISAAAA:8 a=2clOPd4P]
X-AnalysisOut: [AAAA:8 a=CUwWThJu-Sx1_-2QhYEA:9 a=CjuIK1q_8ugA:10 a=lZB815]
X-AnalysisOut: [dzVvQA:10 a=MSl-tDqOz04A:10 a=bDUki_mJ7DgA:10]
Cc: "irs-discuss@ietf.org" <irs-discuss@ietf.org>
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 14:10:30 -0000

IMO the ability to manipulate routing state, context, etc... is what IRS brings to the table and this capability is needed..

Jim Uttaro

-----Original Message-----
From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Alia Atlas
Sent: Tuesday, July 31, 2012 9:45 AM
To: Robert Raszuk
Cc: irs-discuss@ietf.org
Subject: Re: [irs-discuss] IRS Problem Statement Posted

While I am not interested in discussing/refining/bashing OpenFlow on
IRS, except if necessary as to how to compares/contrasts to IRS in
terms of features,  I do recall (sleep helps) that the L3 matching
capabilities are slightly beyond host routes since it does support
arbitrary wildcarding of bits for the flow lookup.

That is still rather different than a longest-prefix match.  It is
still dealing with the forwarding plane and not the RIBs, IGPs, BGP,
LDP, RSVP-TE, etc.

Alia

On Mon, Jul 30, 2012 at 10:22 PM, Alia Atlas <akatlas@gmail.com>; wrote:
> Rob,
>
> 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 <robert@raszuk.net>; 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.
>
> Alia
>
>> 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 <robert@raszuk.net>; 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@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>> _______________________________________________
>>> irs-discuss mailing list
>>> irs-discuss@ietf.org
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
_______________________________________________
irs-discuss mailing list
irs-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/irs-discuss