Re: [irs-discuss] IRS Problem Statement Posted

Robert Raszuk <robert@raszuk.net> Tue, 31 July 2012 02:09 UTC

Return-Path: <robert@raszuk.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 F25BB11E80F5 for <irs-discuss@ietfa.amsl.com>; Mon, 30 Jul 2012 19:09:18 -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 JNxc0HC7IFLw for <irs-discuss@ietfa.amsl.com>; Mon, 30 Jul 2012 19:09:18 -0700 (PDT)
Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 378A411E80EE for <irs-discuss@ietf.org>; Mon, 30 Jul 2012 19:09:18 -0700 (PDT)
Received: (qmail 18485 invoked by uid 399); 31 Jul 2012 02:09:17 -0000
Received: from unknown (HELO ?130.129.19.9?) (robert@raszuk.net@130.129.19.9) by mail1310.opentransfer.com with ESMTPAM; 31 Jul 2012 02:09:17 -0000
X-Originating-IP: 130.129.19.9
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>
In-Reply-To: <CAG4d1rd-g5m6aUb6GQjvu++y6QjHrF1dgsdV7oePMSZaaaomeQ@mail.gmail.com>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=us-ascii
Message-Id: <CDE9865E-E8DE-4754-A0C2-8875ECCAF865@raszuk.net>
X-Mailer: iPad Mail (9B206)
From: Robert Raszuk <robert@raszuk.net>
Date: Mon, 30 Jul 2012 19:09:09 -0700
To: Alia Atlas <akatlas@gmail.com>
Cc: Thomas Nadeau <tnadeau@juniper.net>, Nitin Bahadur <nitinb@juniper.net>, Susan Hares <susan.hares@huawei.com>, James Kempf <james.kempf@ericsson.com>, "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 02:09:19 -0000

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.

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

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.

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.

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