Subject: [irs-discuss] IRS Problem Statement Posted

From: Thomas Nadeau <[email-masked]>
Date: Mon, 30 Jul 2012 14:18:07 -0400

Please review and discuss.

Thanks,

Tom, Alia, Ward

http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt

---

From: James Kempf <[email-masked]>
Date: Mon, 30 Jul 2012 18:11:16 -0400

I don't understand why streaming is specified in this draft. And I don't understand why this draft isn't put in the Forces framework. Forces is a framework explicitedly designed for device to controller communication. Its major drawback it that it is a framework with a hole in the middle, in that there are no specified devices. This draft would fill that hole.

I don't think it is necessary to have a problem statement for router state update. Forces has already established that splitting the control plane into a separate device is, in some cases, an attractive design option. So I think this should be submitted to the Forces working group, or, at least, recast in the Forces framework.

		jak

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Thomas Nadeau
> Sent: Monday, July 30, 2012 11:18 AM
> To: [email-masked]
> Subject: [irs-discuss] IRS Problem Statement Posted
> 
> 
> 
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
>

---

From: Alia Atlas <[email-masked]>
Date: Mon, 30 Jul 2012 18:27:11 -0400

Hi James,

Thanks for your thoughts.   Streaming (as I've heard) is not as good a
description of the desired interface attributes as described in Sec
1.1, the functional overview.

IRS is NOT about having interfaces to the forwarding plane.  That's
what ForCES is focused on.   This is about communication to a router
to install/retrieve routing state into the routing system (FIB, IGPs,
BGP, RSVP-TE, etc.)   IRS is NOT splitting the control plane from the
router.

Are you suggesting that ForCES should drastically expand its scope?

Before we start debating what and whether to expand existing
protocols, I think we need a common understanding of the problem we're
trying to solve and the related framework.

Alia

---

From: Nitin Bahadur <[email-masked]>
Date: Mon, 30 Jul 2012 15:33:06 -0700

Hi James,

This is not about splitting control plane and forwarding plane. It is about exposing network intelligence in the network elements to an external controller.
And it is about allowing an external controller to use that information for enabling network-aware apps. And it is about allowing apps to influence the
network element's RIB (not the FIB directly).

Streaming is essential to allow for operations at scale...and avoid a request/response gated mechanism.

Hope that helps.

Thanks
Nitin

On 7/30/12 3:11 PM, "James Kempf" <[email-masked]> wrote:

                jak

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 30 Jul 2012 18:39:48 -0400

Alia, I do have to disagree with one aspect of your characterization fo 
ForCES.  While the initial design goal was forwarding behavior, the 
protocol design is such that it is usable over a broad range of 
abstraction levels.

Similarly, depending upon exactly what we need, netconf + Netmad/YANG 
may be suitable / useable.

On the other hand, I think that working out the problems and entities 
that need to be modeled first (which probably does need a dedicated 
working group), and then worrying about which protocol meets the 
requirements when we know what exactly we need.  At that point, the 
protocol work can be done wherever appropriate.

yours,
Jitl

---

From: James Kempf <[email-masked]>
Date: Mon, 30 Jul 2012 18:48:39 -0400

Hi Alia,

Perhaps you can explain to me the difference between the state involved in "the routing system (FIB, IGPs, BGP, RSVP-TE, etc.)" and the control plane? The last time I looked, these protocols were all involved in routing control and therefore could reasonably be characterized as components of the control plane, IMHO.

		jak 

> From: Alia Atlas [mailto:[email-masked]] 
> Sent: Monday, July 30, 2012 3:27 PM
> To: James Kempf
> Cc: Thomas Nadeau; [email-masked]
> Subject: Re: [irs-discuss] IRS Problem Statement Posted
> 
> Hi James,
> 
> description of the desired interface attributes as described 
> in Sec 1.1, the functional overview.
> 
> protocols, I think we need a common understanding of the 
> problem we're trying to solve and the related framework.
> 
> Alia
> 
> > I don't understand why streaming is specified in this 
> draft. And I don't understand why this draft isn't put in the 
> Forces framework. Forces is a framework explicitedly designed 
> for device to controller communication. Its major drawback it 
> that it is a framework with a hole in the middle, in that 
> there are no specified devices. This draft would fill that hole.
> >
> > I don't think it is necessary to have a problem statement 
> for router state update. Forces has already established that 
> splitting the control plane into a separate device is, in 
> some cases, an attractive design option. So I think this 
> should be submitted to the Forces working group, or, at 
> least, recast in the Forces framework.
> >
> >                 jak
> >

---

From: Thomas Nadeau <[email-masked]>
Date: Mon, 30 Jul 2012 15:54:02 -0700

On Jul 30, 2012:3:39 PM, at 3:39 PM, "Joel M. Halpern" <[email-masked]> wrote:

> Alia, I do have to disagree with one aspect of your characterization fo ForCES.  While the initial design goal was forwarding behavior, the protocol design is such that it is usable over a broad range of abstraction levels.
> 
> Similarly, depending upon exactly what we need, netconf + Netmad/YANG may be suitable / useable.

	We are not ruling out any existing solutions, either in whole or in part (modified). The goal right now is to define the problem space and a framework of components that can be used to solve that problem.

> On the other hand, I think that working out the problems and entities that need to be modeled first (which probably does need a dedicated working group), and then worrying about which protocol meets the requirements when we know what exactly we need.  At that point, the protocol work can be done wherever appropriate.

	Yes, that is precisely what the goals are right now.

	--Tom

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 30 Jul 2012 16:31:28 -0700

Tom,

Yes indeed .. Clearly defining what problem are you trying to solve would be greatly helpful.

Best,
R.

Sent from my iPad

---

From: <[email-masked]>
Date: Tue, 31 Jul 2012 01:31:44 +0200

Hi,

How much of this is intended (or not) to actually represent a use case for Software-Defined Networking, i.e. become part of the application space for a North-Bound Interface?

Thanks,
Manuel

> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Thomas Nadeau

---

From: Alia Atlas <[email-masked]>
Date: Mon, 30 Jul 2012 20:48:13 -0400

Joel,

As we define the requirements and use-cases, it's possible that
NetConf or ForCES or other options may appear as good options.

We might even want the ability to use different ones as the transfer
protocol; I'm not yet convinced.

The other strong requirement is around security, authorization,
authentication, roles, etc.  I think that will play a role in helping
define what protocols may be suitable to use or extend.

Alia

On Mon, Jul 30, 2012 at 6:39 PM, Joel M. Halpern <[email-masked]> wrote:
> ForCES.  While the initial design goal was forwarding behavior, the protocol
> design is such that it is usable over a broad range of abstraction levels.
>
> On the other hand, I think that working out the problems and entities that
> need to be modeled first (which probably does need a dedicated working
> group), and then worrying about which protocol meets the requirements when
> we know what exactly we need.  At that point, the protocol work can be done
> wherever appropriate.
>
> yours,
> Jitl
>
>
>>> I don't understand why streaming is specified in this draft. And I don't
>>> understand why this draft isn't put in the Forces framework. Forces is a
>>> framework explicitedly designed for device to controller communication. Its
>>> major drawback it that it is a framework with a hole in the middle, in that
>>> I don't think it is necessary to have a problem statement for router
>>> state update. Forces has already established that splitting the control
>>> plane into a separate device is, in some cases, an attractive design option.
>>> So I think this should be submitted to the Forces working group, or, at

---

From: Thomas Nadeau <[email-masked]>
Date: Mon, 30 Jul 2012 20:48:06 -0400

The problem statement/framework are pretty clear that the intent is to
talk directly to the routing system. What happens below that is not part
of the problem we are trying to solve at the moment.

	--Tom

On 7/30/12 4:31 PM, "[email-masked]" <[email-masked]>
wrote:

>Hi,
>
>How much of this is intended (or not) to actually represent a use case
>for Software-Defined Networking, i.e. become part of the application
>space for a North-Bound Interface?
>
>
>Thanks,
>Manuel
>
>

---

From: Alia Atlas <[email-masked]>
Date: Mon, 30 Jul 2012 20:53:21 -0400

Hi James,

The routing system components are certainly part of a router's control
plane - but not all of it.  The idea of IRS involves sub-interfaces to
the different layers in the routing system.

Can you clarify what you are asking as it relates to ForCES and IRS?
I don't feel that we're on the same page yet.

Alia

---

From: Alia Atlas <[email-masked]>
Date: Mon, 30 Jul 2012 20:55:30 -0400

Rob,

We've been trying.  I've written semi-copious words so far.
I'd be happy to discuss with you in person as well and get your
thoughts on reasonable use-cases.

Describing an elephant for the first time is always tricky.

Perhaps you could describe your perspective on the problem and what
you think is unclear.

Regards,
Alia

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 30 Jul 2012 18:11:16 -0700

What is not clear for me is ability from arbitrary entities to be able to write to BGP or ISIS at sort of ad-hoc streaming. I do not see anything good can be seen as result of this. 

Exporting information is fine - no objection at all.

However for programming state into dynamic system the entity which writes in should be the master and not the slave which unfortunately as of now it looks like it is the latter.

Perhaps you have in mind just adding bunch of ACLs on the edges, perhaps just add static routes, perhaps insert network statements into BGP configuration. But till details are defined and till we understand how is this any better from already standards based tools to do the same I think it is well premature to judge any benefit from the IRS framework.

Best Rgs,
R.

Sent from my iPad

---

From: Alia Atlas <[email-masked]>
Date: Mon, 30 Jul 2012 21:23:00 -0400

Rob,

> What is not clear for me is ability from arbitrary entities to be able to write to BGP or ISIS at sort of ad-hoc streaming. I do not see anything good can be seen as result of this.

[Alia] Arbitrary AUTHORIZED entities - and we will probably need
policy around what type of state and policy can be added so that basic
routing assumptions aren't broken.

> Exporting information is fine - no objection at all.

[Alia] Kind of you - a feedback loop is important.

> However for programming state into dynamic system the entity which writes in should be the master and not the slave which unfortunately as of now it looks like it is the latter.

[Alia] Are you suggesting the application should be the master of the
information?  Or the router?  The application could add information
and own (based upon its authorization and role hierarchy) that data as
far as not having it removed.   I'm a bit puzzled by where you are
obtaining this assumption from?

> Perhaps you have in mind just adding bunch of ACLs on the edges, perhaps just add static routes, perhaps insert network statements into BGP configuration. But till details are defined and till we u…

[Alia] Do you mean because we haven't ironed out absolutely all of the
details, requirements and data-models, there is no point in discussing
what would be useful and working on doing so?

[Alia]  I've asked for your concerns, thoughts on the
problem-statement, and possible use-cases.  Instead of engaging, I
feel like you've thrown up your hands and said "it's too uncertain"
when we are clearly in the early stages of defining those things.

Alia

---

From: Susan Hares <[email-masked]>
Date: Tue, 31 Jul 2012 01:24:39 +0000

Nitin: 

Exposing some network intelligence can either be done in detail or in some amount of summarization. 
If you are doing detail, you have bandwidth issues. If you are doing summarization or opacity, you are talking about layers of information. 

Apps need to find out what they need to get. They do not need all the details - just the fact they can get from point A to Point B (or for multi-cast B/C/D). They need to where they can go to date other applications.  They need a match-maker for the application who determine where the applications shall flow.  Now, if they are smart - like people going out to eat - they pick several ways go to eat traffic.  

The network orchestration then serves to be the paths to the place to eat.  This can either be distributed or centralized.  

If we have an Interface to routing, it need to have a two-layer concept of exposing information.  

Sue Hares 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Nitin Bahadur
Sent: Monday, July 30, 2012 3:33 PM
To: James Kempf; Thomas Nadeau; [email-masked]
Subject: Re: [irs-discuss] IRS Problem Statement Posted

Hi James,

Hope that helps.

Thanks
Nitin

                jak

---

From: Susan Hares <[email-masked]>
Date: Tue, 31 Jul 2012 01:30:55 +0000

Joel:

+1.  IRS requires many different things.  We can use netconf, netmod+yang, ForCES.

As my draft states, ForCES is likely to be equivalent or better than ONF. (OFS: [0.9][1.0][1.1][1.2]). See my detailed review, and the 2nd drafts recasting of ONF as ForCES LFB.

We need to look at the requirements of the routing system and your proposed multiple interfaces. 

Sue 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Nadeau
Sent: Monday, July 30, 2012 3:54 PM
To: Joel M. Halpern
Cc: Thomas Nadeau; James Kempf; [email-masked]; Alia Atlas
Subject: Re: [irs-discuss] IRS Problem Statement Posted

	--Tom

---

From: Nitin Bahadur <[email-masked]>
Date: Mon, 30 Jul 2012 18:39:07 -0700

Hi Susan,

    You've expressed my thoughts very succinctly. I fully agree with all you said. IRS is nothing but a middleware IMO. 

An orchestrator has 3 layers:

The top layer exposes the northbound Apis to apps - I want a path from A to B with a constrain on low latency. That's all the app should need to say.

The bottom layer fetches topology, stats and other data from network elements and programs the network elements.

And the middle layer is the business layer that takes user input from northbound Apis, takes input from bottom layer; munches on the data and converts it into rules for the bottom layer to program.

So IRS needs to define interfaces for both the lower layer and the upper layer.

Thanks
Nitin

---

From: Alia Atlas <[email-masked]>
Date: Mon, 30 Jul 2012 21:39:35 -0400

Sue,

I certainly agree that we want IRS to have the ability to express
information at different abstraction layers and filtered on request.

There may still be a gap between the "network OS abstractions" and IRS
sub-interfaces; I'd be surprised if there weren't.  IRS is to provide
the bottom-up control strings.

IMHO, it's reasonable to have an entity that manages the translation.
For instance, one doesn't need a PCE-equiv in every application - nor
in every router; that might be an entity in between.

The quantity of information is part of why explicit filtering and
hopefully abstraction layers should be built into the data-models.

Alia

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 30 Jul 2012 18:48:06 -0700

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.

---

From: Alia Atlas <[email-masked]>
Date: Mon, 30 Jul 2012 21:58:09 -0400

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.   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

---

From: Nitin Bahadur <[email-masked]>
Date: Mon, 30 Jul 2012 19:06:42 -0700

[ off-topic ]

Today in IDR, Microsoft folks presented on running data centers using BGP. So I guess we should put OSPF & ISIS to rest. We can use BGP for everything.

[ / off-topic ]

Openflow abstractions are at the forwarding level. IRS does not compete with that.

[ rant ]
Did I just hear that you've convinced your company to replace all of its networking gear with OF gear and a uber powerful controller.
[ / rant ]

Thanks
Nitin

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 30 Jul 2012 19:09:09 -0700

Alia,

> 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

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 30 Jul 2012 19:10:49 -0700

> Today in IDR, Microsoft folks presented on running data centers using BGP. So I guess we should put OSPF & ISIS to rest. We can use BGP for everything.

No

> Did I just hear that you've convinced your company to replace all of its networking gear with OF gear and a uber powerful controller.

No

Thx,
R.

---

From: Alia Atlas <[email-masked]>
Date: Mon, 30 Jul 2012 22:22:52 -0400

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.

> 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 valid…

[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…

[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

---

From: Alia Atlas <[email-masked]>
Date: Tue, 31 Jul 2012 09:44:58 -0400

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

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Tue, 31 Jul 2012 14:10:06 +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: [email-masked] [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: Tuesday, July 31, 2012 9:45 AM
To: Robert Raszuk
Cc: [email-masked]
Subject: Re: [irs-discuss] IRS Problem Statement Posted

Alia

---

From: James Kempf <[email-masked]>
Date: Tue, 31 Jul 2012 11:59:51 -0400

> 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.
> 

Agree.

		jak

---

From: James Kempf <[email-masked]>
Date: Tue, 31 Jul 2012 12:11:37 -0400

> [ off-topic ]
> 
> Today in IDR, Microsoft folks presented on running data 
> centers using BGP. So I guess we should put OSPF & ISIS to 
> rest. We can use BGP for everything.
> 

Yeah, right. Then when it breaks due to being used for something it wasn't designed, we can spend the next 10 years in IETF working groups coming up with fixes. And have to hire high priced BFG gurus to configure and keep it running in the meantime. :-) 

> Did I just hear that you've convinced your company to replace 
> all of its networking gear with OF gear and a uber powerful 
> controller.
> [ / rant ]

Wollen Sie dann weiter die Unterhaltung auf Deutsch haben?

Anyway, I've been working with OpenFlow on and off since 2006. You can do stuff like:

- make an access/aggregation network with a couple hundred switches look like a gigantic router to the outside world by aggregating the interfaces (and thereby make it easier to manage)

- do application specific flow steering for chained processing in middleboxes (complaints about DPI please to /dev/null)

- run a 3GPP/LTE mobile core with the control plane including routing completely in a cloud instead of only the mobility mangement part

- and finally, as Google has demonstrated, run your network at 90% capacity as opposed to 30% (and, yes, I know that the network was rather special and perhaps not characteristic of a provider network but it still shows what you can do)

But it is not magic, there are lots of problems that need work, and it could still go badly wrong. Right now, it is at the peak of the Gardner hype curve, give it another year, and everybody will be trashing it, unless of course the hype curve moves up another notch.

			jak

---

From: Alia Atlas <[email-masked]>
Date: Tue, 31 Jul 2012 12:16:33 -0400

It is impressive what can be done with even the limited control and
scalability that Openflow provides.

IRS is to provide additional controls at the multiple layers in the
routing system to facilitate application-level control/intelligence

Alia

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 31 Jul 2012 18:16:36 +0200

Jim,

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

Manipulating routing state from outside of routing protocols seems to me 
like tampering with jet engines during the flight.

Alia,

There is no point to keep arguing about IRS framework .. it can call to 
address world hunger or propose to turn Sahara into rain forest.

I think we need to wait and see actual protocol(s) proposals which 
write/stream into current routing systems as opposed to industry 
alternatives which target to write to forwarding layer directly or use 
already proposed IETF tools like NETCONF which already provide a very 
good provisioning abstraction today.

My observation is that IRS is yet one more attempt to wave the SDN 
banner in the IETF without much substance behind it.

Best,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 31 Jul 2012 18:19:54 +0200

Alia,

> That is still rather different than a longest-prefix match.

I can do longest prefix match today using OF priority in each table.

Sure maybe it is not optimal as compared with nice tree lookup 
alternatives we see today with pure IP destination based lookup and of 
course there is room for improvement. But let's work based on the 
correct assumptions.

> It is

And IMHO this is a feature not a bug.

Best regards,
R.

---

From: James Kempf <[email-masked]>
Date: Tue, 31 Jul 2012 12:26:46 -0400

Hi Alia,

With respect to the interfaces defined in RFC 5810, it seems to me that IRS is not proposing to replace existing routing protocols (OSPF, IS-IS) so it seems it would be the Fp interface. But I have not studied the Forces docs in detail recently so I may be in error.

		jak 

> Sent: Monday, July 30, 2012 5:53 PM
> To: James Kempf
> The routing system components are certainly part of a 
> router's control plane - but not all of it.  The idea of IRS 
> involves sub-interfaces to the different layers in the routing system.
> 
> > Perhaps you can explain to me the difference between the 
> state involved in "the routing system (FIB, IGPs, BGP, 
> RSVP-TE, etc.)" and the control plane? The last time I 
> looked, these protocols were all involved in routing control 
> and therefore could reasonably be characterized as components 
> of the control plane, IMHO.
> >
> >                 jak
> >
> >> protocols, I think we need a common understanding of the problem 
> >> we're trying to solve and the related framework.
> >>
> >> Alia
> >>
> >> draft. And I don't understand why this draft isn't put in 
> the Forces 
> >> framework. Forces is a framework explicitedly designed for 
> device to 
> >> controller communication. Its major drawback it that it is a 
> >> framework with a hole in the middle, in that there are no 
> specified 
> >> devices. This draft would fill that hole.
> >> >
> some cases, 
> >> an attractive design option. So I think this should be 
> submitted to 
> >> the Forces working group, or, at least, recast in the Forces 
> >> framework.
> >> >
> >> >                 jak
> >> >

---

From: Alia Atlas <[email-masked]>
Date: Tue, 31 Jul 2012 12:30:34 -0400

Hi James,

This is one of the key differences - ForCES is about programming the
forwarding plane.  IRS is about interfaces to the routing system - the
lowest it goes is to the RIB layer.  IMHO, this gives good control and
abstraction - no need to model forwarding plane differences.  That's
what the router OS is for.

I do discuss this briefly in the IRS problem-statement.
I'd also be happy to chat between WGs.

Alia

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 31 Jul 2012 09:30:55 -0700

James, 

	While an implicit goal to not invent anything that can be recycled and still meet the requirements, we are at present not proposing any solutions. We are trying to identify the problem space and define a framework containing the components needed to solve the problem(s).

	--Tom

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 31 Jul 2012 12:25:46 -0400

>like tampering with jet engines during the flight.

	Network operators modify the routing system while it is in flight all
the time using other interfaces, so I fail to see why this is so alarming.

>banner in the IETF without much substance behind it.

	We would appreciate keeping the discussion focused on whether or not this
is a good problem to solve, and identifying that clearly. We are not
interested in 
pontifications about the IETF, its management or policies on this list. 8)

	Thanks,

	--Tom

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 31 Jul 2012 12:32:49 -0400

On Tue, Jul 31, 2012 at 12:19 PM, Robert Raszuk <[email-masked]> wrote:

> Sure maybe it is not optimal as compared with nice tree lookup alternatives
> we see today with pure IP destination based lookup and of course there is
> room for improvement. But let's work based on the correct assumptions.

At the expense of steering this discussion into a further tangent (and
not offend any work youve done in this space - it is a novel idea;
i have done similar things with broadcom chips myself many seasons back):
The problem with using ACL tables on the switches is their size.
They range anywhere from 128 entries to a few K. Sure, you can perform
acrobatics with re-populating them doing BGP or a medium size network
but why not use the IP functional blocks which exists _on the same chip_
with much better organized tables for ip forwarding etc?

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 31 Jul 2012 12:40:45 -0400

> what the router OS is for.

Ok, guess i am going to have say something then;->
While ForCES did start with intent to do control-datapath interfacing,
given that:  we have a data model (and language); a protocol that is
agnostic of what the entity being configured is - over the last few
years it has been used for anything that can be modelled using
the ForCES language. Basically model it as an LFB and you are good
to go.
I am actually presenting on how we do parts of the FE management
plane via ForCES at a session today. In our implementation, this
is how we do remote debug settings, change syslog levels etc.
Nothing to do with a FIB table programming etc...

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 31 Jul 2012 12:43:04 -0400

On Tue, Jul 31, 2012 at 12:40 PM, Jamal Hadi Salim <[email-masked]> wrote:
> Basically model it as an LFB and you are good
> to go.

Essentially from this perspective, theres a lot of parallels with protobufs or
thrift.

cheers,
jamal

---

From: Alia Atlas <[email-masked]>
Date: Tue, 31 Jul 2012 12:43:32 -0400

Yes, I've heard the comments that ForCES may have good characteristics
for the protocol aspects of IRS.  I think we need to focus on
discussing the problem and use-cases - before we start seriously
considering protocols.

More information about them and their potential relevance is always welcome.

Alia

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 31 Jul 2012 12:48:51 -0400

> discussing the problem and use-cases - before we start seriously

nod.

cheers,
jamal