Re: [irs-discuss] IRS Problem Statement Posted

["UTTARO, JAMES" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of Alia Atlas
Sent: Tuesday, July 31, 2012 9:45 AM
To: Robert Raszuk
Cc: [e-mail]
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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
_______________________________________________
irs-discuss mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/irs-discuss