Re: [irs-discuss] IRS Problem Statement Posted

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