Re: [irs-discuss] IRS Problem Statement Posted

Alia Atlas <akatlas@gmail.com> Tue, 31 July 2012 13:45 UTC

Return-Path: <akatlas@gmail.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 752E121F8618 for <irs-discuss@ietfa.amsl.com>; Tue, 31 Jul 2012 06:45:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 jSkyq-25qjRL for <irs-discuss@ietfa.amsl.com>; Tue, 31 Jul 2012 06:45:00 -0700 (PDT)
Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 222EF21F84EF for <irs-discuss@ietf.org>; Tue, 31 Jul 2012 06:44:59 -0700 (PDT)
Received: by ggnc4 with SMTP id c4so6538639ggn.31 for <irs-discuss@ietf.org>; Tue, 31 Jul 2012 06:44:58 -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:content-transfer-encoding; bh=XKIStzSVhCWnRBgejxOMBYuJCUeZzKSSHQCeg98bzN0=; b=MuKZuHxW9tXBpsUtAJmD4YB9FAja6ZQ9svWF6VwxOPop5iwJhw9kj3T2+tFRhfsuuq z1/0VAYqa5L7XL0pQS6pPFDgGVcmvchvt4JjDU03qZxtRD/TZz83IFLKW7grnzBQMCDz zLvv2y64jYINWcrRB7LEXy2TRlQje9SQcbsfK2/B9O1W8SgeHKpypz3gK7NPlGEF2tcF J5V1tcYws0aX7hXJPrhA3NO+27107jwBzl7G+Qvfl5lnhLIht84VOaESBQSHr5wbTSjS DBqyrZF2k7aqZObH/4fp6uH4DJh36TgYI5JPpPO7HUtqRLcueUFZxVSChzkQ2Do1LyIu pusw==
MIME-Version: 1.0
Received: by 10.50.104.228 with SMTP id gh4mr639913igb.71.1343742298283; Tue, 31 Jul 2012 06:44:58 -0700 (PDT)
Received: by 10.50.34.169 with HTTP; Tue, 31 Jul 2012 06:44:58 -0700 (PDT)
In-Reply-To: <CAG4d1rcL7ttJctimrQEvxaV7L=3QZSCvfTaX43YFyTJF0nYBzA@mail.gmail.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>
Date: Tue, 31 Jul 2012 09:44:58 -0400
Message-ID: <CAG4d1redZy7=C2asceFYZsZoVsYh_XMLx5+GfxRio76t-97vHg@mail.gmail.com>
From: Alia Atlas <akatlas@gmail.com>
To: Robert Raszuk <robert@raszuk.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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 13:45:01 -0000

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