Subject: [irs-discuss] Thoughts on draft-ward-irs-framework
From: Russ White <[email-masked]>
To: [email-masked]
Date: Tue, 31 Jul 2012 20:41:57 -0400
List-Id: "Interface to The Internet Routing System \(IRS\)" <irs-discuss.ietf.org>

This framework is well put together, but I'd like to make a couple of
suggestions/comments/put some ideas forward.

1. I think the draft struggles somewhat with describing something that's
already in all routers today because it's attempting to describe an
interface into the RIB that's somehow separate, or stands beside, the
existing interfaces into the RIB. I would gently suggest that describing
this entire idea as an "off board routing process," much like a BGP
process on an existing implementation, might clarify things a bit, and
make the model easier to understand.

Consider --any given routing process already installs routes into the
routing table, including the concept of preference. BGP routing
processes, specifically, also have import and export capabilities into
various VRFs. All routing processes also have redistribution capabilities.

What if you modeled this entire thing as two types of "off board routing
processes," one that only imports data from the RIB for northbound
consumption (topology information), and one that interacts with the RIB
like any other routing process would for southbound control as well as
northbound consumption?

It's going to be much easier to interact with the other routing
protocols on the box without a lot of "special pleading" if IRS is a
process that's peer to BGP, OSPF, IS-IS, et al. Take the instance of
link down notifications --all the implementations I know of process link
downs in the RIB, and the RIB then notifies the routing protocol... If
you're hooking into the RIB locally, then, you need to hook into link
down detection specifically and intentionally. If IRS is a routing
process, the RIB will notify the northbound interface as a matter of
course in processing link down notifications.

I hope that makes sense, but I'm glad to sit and discuss if it doesn't.

2. There needs to be a way to mark routes inserted in the RIB with a
process ID of some sort. This would come naturally if the entire IRS
idea were to put an "off board routing process" on the box that
interacts with existing on board processes (see #1 above), but as the
draft stands, there's no way to insert a process id into the RIB. This
is crucial for redistribution, and I suspect redistribution is going to
be a huge problem to address in the long term, since the routes injected
by IRS, however they're injected, will need to interact with the dynamic
protocols running on the box.

3. There are a ton of other possible use cases, if more are
needed/wanted to support the reasoning behind the draft. Choosing the
optimal exit from any given edge (OER in cisco lingo), a superset of
Flowspec to combat DDoS is another (mentioned tangentially, but not as a
use case), live/live is another (packet replication and choosing the
best of two identical streams) --and there are others... Some of these
might actually be more interesting use cases than are currently
described in the draft.

More if I get the chance to reread it in a little more depth later.

HTH

Russ

-- 
<><
[email-masked]
[email-masked]

Date: Tue, 31 Jul 2012 19:08:47 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: Alia Atlas <[email-masked]>
Cc: [email-masked]
Subject: Re: [irs-discuss] IRS problem statement and NETCONF/YANG
Reply-To: Juergen Schoenwaelder <[email-masked]>

On Tue, Jul 31, 2012 at 12:56:04PM -0400, Alia Atlas wrote:
> Hi Juergen,
> 
> Thanks very much for your informative email.  I certainly have more
> reading to do on NetConf and would welcome help in correcting the
> perspective in the appendix about NetConf.
> 
> It sounds like NetConf could be a good candidate protocol when we get
> there.  As I've said, we've got to focus on clearly describing the
> problem and vertical use-cases; then we should be able to think about
> and evaluate protocol possibilities.
> 
> Of course, it'd be useful to have a good accurate and up-to-date
> understanding of the capabilities of each protocol before then.
> 
> If you have time and interest, I'd be happy to chat off-line tomorrow
> and have more NetConf/Yang clue installed.

I agree that you should focus on "clearly describing the problem and
vertical use-cases" first since that will help to understand the
requirements. If you need NETCONF/YANG input, I am happy to help.
I am around until Friday.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

Date: Tue, 31 Jul 2012 12:56:04 -0400
From: Alia Atlas <[email-masked]>
To: Juergen Schoenwaelder <[email-masked]>
Cc: [email-masked]
Subject: Re: [irs-discuss] IRS problem statement and NETCONF/YANG

Hi Juergen,

Thanks very much for your informative email.  I certainly have more
reading to do on NetConf and would welcome help in correcting the
perspective in the appendix about NetConf.

It sounds like NetConf could be a good candidate protocol when we get
there.  As I've said, we've got to focus on clearly describing the
problem and vertical use-cases; then we should be able to think about
and evaluate protocol possibilities.

Of course, it'd be useful to have a good accurate and up-to-date
understanding of the capabilities of each protocol before then.

If you have time and interest, I'd be happy to chat off-line tomorrow
and have more NetConf/Yang clue installed.

Alia

On Tue, Jul 31, 2012 at 10:49 AM, Juergen Schoenwaelder
<[email-masked]> wrote:
> Hi,
>
> reading through the problem statement posted at
>
> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt
>
> I noticed a number of statements concerning NETCONF and YANG that
> probably need to be corrected. For more background where NETCONF and
> YANG is, you may want to consult the tutorial slides posted at
>
> http://cnds.eecs.jacobs-university.de/slides/2012-ietf-84-netconf-yang.pdf
>
> and consult the documents referenced in the slides. Some more detailed
> comments:
>
> :   Finally, the IETF's Network Configuration (or NetConf) protocol has
> :   made many strides at overcoming most of the limitations around
> :   configuration that were just described.  However, the lack of
> :   standard data models have hampered the adoption of NetConf.
>
> The NETMOD working group has been chartered to work on common core
> data models and currently has core data models for the configuration
> of network interfaces, ip interfaces and a core routing configuration
> data model in WG last call:
>
> http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-04
> http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-05
> http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-05
>
> :   While NetConf has solved many of the deficiencies present in SNMP in
> :   terms of configuration, it still does not satisfy a number of
> :   requirements needed to manage today's routing information.  First,
> :   the lack of standard data models have hampered the adoption of
> :   NetConf; a significant amount of per-vendor customization is still
> :   needed.  The transport mechanisms that are currently defined (e.g.,
> :   SOAP/BEEP) for NetConf are not those commonly used by modern
> :   applications (e.g., ReST or JSON).
>
> The default to implement transport for NETCONF is SSH. There is
> another transport over TLS. The BEEP and SOAP transports are on their
> way to be declared historic. That said, there is work underway to
> define a JSON / REST API to YANG modelled NETCONF data stores.
>
> http://tools.ietf.org/html/draft-bierman-netconf-yang-api-00
> http://tools.ietf.org/html/draft-lhotka-yang-json-00
>
> :   NetConf primarily facilitates configuration rather than reading of
> :   state or handling asynchronous events.
>
> Not sure what primarily facilitates means but NETCONF does support all
> three functions. NETCONF allows read access to all existing SNMP
> instrumentation of devices.
>
> :   NetConf matches up to the key needed aspects as follows
> :
> :   Multiple Simultaneous Asynchronous Operations:   Not Possible
>
> The NETCONF protocol tags RPC invocations with a message-id that is
> echoed back in RPC replies, allowing asynchronous operations. NETCONF
> also provides global and partial locks to properly deal concurrent
> operations received via multiple channels.
>
> :   Configuration Not Re-Processed:   Not Possible
>
> I simply do not understand the definition of this aspect. You document
> says:
>
> :   Configuration Not Re-Processed:   When an IRS operation is processed,
> :      it does not require that any of the configuration be processed.
> :      I.e., the desired behavior is orthogonal to the static
> :      configuration.
>
> A clarficiation is needed what you mean with this. Anyway, NETCONF
> distinguishes between different configuration data stores. If you want
> to distinguish between changes that affect only the current behaviour
> but not say the next startup behaviour (i.e. the changes do not
> persist), then this is already supported by NETCONF.
>
> Perhaps your concern is that making a change requires to reprocess the
> whole configuration? In that case, this is clearly not required
> anywhere by the NETCONF protocol specification. In fact, the
> edit-config operation allows to send detailed configuration change
> sets to a NETCONF server.
>
> :   Duplex:   Not Possible - strict pull model.
>
> NETCONF does have support for event notifications that are pushed by
> the device. The initiation of the session is client to server for the
> existing transports - but this is mostly a property of the transports.
> Some vendors use non-standard extensions for the SSH transport to
> support device initiated sessions.
>
> :   High-Throughput:   Unlikely - Can depend on configuration size
>
> Well, this is ill defined in the first place. Your definition is:
>
> :   High-Throughput:   At a minimum, the IRS Agent and associated router
> :      should be able to handle hundreds of simple operations per second.
>
> So what is a "simple operation"? I am rather optimistic that it is
> possible to do some "simple operation" in NETCONF at the requested
> speed. To be useful, you really need to be more precise.
>
> :   Responsive:   Unlikely - Can depend on configuration size
>
> Again, this is under specified. Your definition is:
>
> :   Responsive:   It should be possible to complete simple operations
> :      within a sub-second time-scale.
>
> I am sure NETCONF servers easily respond within a sub-second
> time-scale. We have several implementors here at the IETF, I
> am sure they can provide more concrete information about the
> efficiency aspects.
>
> :   Multi-Channel:   Not Possible
>
> NETCONF allows to use multiple SSH or TLS sessions (hence multiple TCP
> sessions) and it provides the needed coordination primitives. In
> addition, the SSH transport can be used to run multiple SSH channels
> multiplexed over a single TCP session.
>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 31 Jul 2012 12:48:51 -0400
To: Alia Atlas <[email-masked]>
Cc: Thomas Nadeau <[email-masked]>, James Kempf <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS Problem Statement Posted

On Tue, Jul 31, 2012 at 12:43 PM, Alia Atlas <[email-masked]> wrote:
> 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.

nod.

cheers,
jamal

Date: Tue, 31 Jul 2012 12:43:32 -0400
From: Alia Atlas <[email-masked]>
To: Jamal Hadi Salim <[email-masked]>
Cc: Thomas Nadeau <[email-masked]>, James Kempf <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS Problem Statement Posted

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

On Tue, Jul 31, 2012 at 12:40 PM, Jamal Hadi Salim <[email-masked]> wrote:
> On Tue, Jul 31, 2012 at 12:30 PM, Alia Atlas <[email-masked]> wrote:
>
>> 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.
>
> 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
To: Alia Atlas <[email-masked]>
Cc: Thomas Nadeau <[email-masked]>, James Kempf <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS Problem Statement Posted

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: Jamal Hadi Salim <[email-masked]>
Date: Tue, 31 Jul 2012 12:40:45 -0400
To: Alia Atlas <[email-masked]>
Cc: Thomas Nadeau <[email-masked]>, James Kempf <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS Problem Statement Posted

On Tue, Jul 31, 2012 at 12:30 PM, Alia Atlas <[email-masked]> wrote:

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

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:32:49 -0400
To: [email-masked]
Cc: "[email-masked]" <[email-masked]>, Alia Atlas <[email-masked]>
Subject: Re: [irs-discuss] IRS Problem Statement Posted

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

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

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: Thomas Nadeau <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 31 Jul 2012 12:25:46 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [irs-discuss] IRS Problem Statement Posted

On 7/31/12 9:16 AM, "Robert Raszuk" <[email-masked]> wrote:

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

	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.

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

	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=20
pontifications about the IETF, its management or policies on this list. 8)

	Thanks,

	--Tom

From: Thomas Nadeau <[email-masked]>
Date: Tue, 31 Jul 2012 09:30:55 -0700
To: James Kempf <[email-masked]>
Cc: Thomas Nadeau <[email-masked]>, "[email-masked]" <[email-masked]>, Alia Atlas <[email-masked]>
Subject: Re: [irs-discuss] IRS Problem Statement Posted

	James,=20

	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

On Jul 31, 2012:9:26 AM, at 9:26 AM, James Kempf =
<[email-masked]> wrote:

> Hi Alia,
>=20
> 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.
>=20
> 		jak=20
>=20
>> -----Original Message-----
>> From: Alia Atlas [mailto:[email-masked]]=20
>> Sent: Monday, July 30, 2012 5:53 PM
>> To: James Kempf
>> Cc: Thomas Nadeau; [email-masked]
>> Subject: Re: [irs-discuss] IRS Problem Statement Posted
>>=20
>> Hi James,
>>=20
>> The routing system components are certainly part of a=20
>> router's control plane - but not all of it.  The idea of IRS=20
>> involves sub-interfaces to the different layers in the routing =
system.
>>=20
>> 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.
>>=20
>> Alia
>>=20
>>=20
>> On Mon, Jul 30, 2012 at 6:48 PM, James Kempf=20
>> <[email-masked]> wrote:
>>> Hi Alia,
>>>=20
>>> Perhaps you can explain to me the difference between the=20
>> state involved in "the routing system (FIB, IGPs, BGP,=20
>> RSVP-TE, etc.)" and the control plane? The last time I=20
>> looked, these protocols were all involved in routing control=20
>> and therefore could reasonably be characterized as components=20
>> of the control plane, IMHO.
>>>=20
>>>                jak
>>>=20
>>>> -----Original Message-----
>>>> 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
>>>>=20
>>>> Hi James,
>>>>=20
>>>> Thanks for your thoughts.   Streaming (as I've heard) is=20
>> not as good a
>>>> description of the desired interface attributes as=20
>> described in Sec=20
>>>> 1.1, the functional overview.
>>>>=20
>>>> IRS is NOT about having interfaces to the forwarding plane.  That's
>>>> what ForCES is focused on.   This is about communication=20
>> to a router
>>>> to install/retrieve routing state into the routing system=20
>> (FIB, IGPs,
>>>> BGP, RSVP-TE, etc.)   IRS is NOT splitting the control=20
>> plane from the
>>>> router.
>>>>=20
>>>> Are you suggesting that ForCES should drastically expand its scope?
>>>>=20
>>>> Before we start debating what and whether to expand existing=20
>>>> protocols, I think we need a common understanding of the problem=20
>>>> we're trying to solve and the related framework.
>>>>=20
>>>> Alia
>>>>=20
>>>> On Mon, Jul 30, 2012 at 6:11 PM, James Kempf=20
>>>> <[email-masked]> wrote:
>>>>> I don't understand why streaming is specified in this
>>>> draft. And I don't understand why this draft isn't put in=20
>> the Forces=20
>>>> framework. Forces is a framework explicitedly designed for=20
>> device to=20
>>>> controller communication. Its major drawback it that it is a=20
>>>> framework with a hole in the middle, in that there are no=20
>> specified=20
>>>> devices. This draft would fill that hole.
>>>>>=20
>>>>> I don't think it is necessary to have a problem statement
>>>> for router state update. Forces has already established that=20
>>>> splitting the control plane into a separate device is, in=20
>> some cases,=20
>>>> an attractive design option. So I think this should be=20
>> submitted to=20
>>>> the Forces working group, or, at least, recast in the Forces=20
>>>> framework.
>>>>>=20
>>>>>                jak
>>>>>=20
>>>>>> -----Original Message-----
>>>>>> From: [email-masked]=20
>>>>>> [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
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> Please review and discuss.
>>>>>>=20
>>>>>> Thanks,
>>>>>>=20
>>>>>> Tom, Alia, Ward
>>>>>>=20
>>>>>>=20
>>>>>> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt
>>>>>>=20
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> irs-discuss mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>>>>=20
>>>>> _______________________________________________
>>>>> irs-discuss mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>>=20
>>=20
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
>=20

Date: Tue, 31 Jul 2012 12:30:34 -0400
From: Alia Atlas <[email-masked]>
To: James Kempf <[email-masked]>
Cc: Thomas Nadeau <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS Problem Statement Posted

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

On Tue, Jul 31, 2012 at 12:26 PM, James Kempf <[email-masked]> wr=
ote:
> Hi Alia,
>
> With respect to the interfaces defined in RFC 5810, it seems to me that I=
RS 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 do=
cs in detail recently so I may be in error.
>
>                 jak
>
>> -----Original Message-----
>> From: Alia Atlas [mailto:[email-masked]]
>> Sent: Monday, July 30, 2012 5:53 PM
>> To: James Kempf
>> Cc: Thomas Nadeau; [email-masked]
>> Subject: Re: [irs-discuss] IRS Problem Statement Posted
>>
>> 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
>>
>>
>> On Mon, Jul 30, 2012 at 6:48 PM, James Kempf
>> <[email-masked]> wrote:
>> > 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
>> >
>> >> -----Original Message-----
>> >> 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,
>> >>
>> >> 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
>> >>
>> >> On Mon, Jul 30, 2012 at 6:11 PM, James Kempf
>> >> <[email-masked]> wrote:
>> >> > 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
>> >> >>
>> >> >>
>> >> >>
>> >> >> Please review and discuss.
>> >> >>
>> >> >> Thanks,
>> >> >>
>> >> >> Tom, Alia, Ward
>> >> >>
>> >> >>
>> >> >> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt
>> >> >>
>> >> >>
>> >> >> _______________________________________________
>> >> >> irs-discuss mailing list
>> >> >> [email-masked]
>> >> >> https://www.ietf.org/mailman/listinfo/irs-discuss
>> >> >>
>> >> > _______________________________________________
>> >> > irs-discuss mailing list
>> >> > [email-masked]
>> >> > https://www.ietf.org/mailman/listinfo/irs-discuss
>> >>
>>

From: James Kempf <[email-masked]>
To: Alia Atlas <[email-masked]>
Date: Tue, 31 Jul 2012 12:26:46 -0400
Accept-Language: en-US
acceptlanguage: en-US
Cc: Thomas Nadeau <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS Problem Statement Posted

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=20

> -----Original Message-----
> From: Alia Atlas [mailto:[email-masked]]=20
> Sent: Monday, July 30, 2012 5:53 PM
> To: James Kempf
> Cc: Thomas Nadeau; [email-masked]
> Subject: Re: [irs-discuss] IRS Problem Statement Posted
>=20
> Hi James,
>=20
> The routing system components are certainly part of a=20
> router's control plane - but not all of it.  The idea of IRS=20
> involves sub-interfaces to the different layers in the routing system.
>=20
> 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.
>=20
> Alia
>=20
>=20
> On Mon, Jul 30, 2012 at 6:48 PM, James Kempf=20
> <[email-masked]> wrote:
> > Hi Alia,
> >
> > Perhaps you can explain to me the difference between the=20
> state involved in "the routing system (FIB, IGPs, BGP,=20
> RSVP-TE, etc.)" and the control plane? The last time I=20
> looked, these protocols were all involved in routing control=20
> and therefore could reasonably be characterized as components=20
> of the control plane, IMHO.
> >
> >                 jak
> >
> >> -----Original Message-----
> >> 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,
> >>
> >> Thanks for your thoughts.   Streaming (as I've heard) is=20
> not as good a
> >> description of the desired interface attributes as=20
> described in Sec=20
> >> 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=20
> to a router
> >> to install/retrieve routing state into the routing system=20
> (FIB, IGPs,
> >> BGP, RSVP-TE, etc.)   IRS is NOT splitting the control=20
> plane from the
> >> router.
> >>
> >> Are you suggesting that ForCES should drastically expand its scope?
> >>
> >> Before we start debating what and whether to expand existing=20
> >> protocols, I think we need a common understanding of the problem=20
> >> we're trying to solve and the related framework.
> >>
> >> Alia
> >>
> >> On Mon, Jul 30, 2012 at 6:11 PM, James Kempf=20
> >> <[email-masked]> wrote:
> >> > I don't understand why streaming is specified in this
> >> draft. And I don't understand why this draft isn't put in=20
> the Forces=20
> >> framework. Forces is a framework explicitedly designed for=20
> device to=20
> >> controller communication. Its major drawback it that it is a=20
> >> framework with a hole in the middle, in that there are no=20
> specified=20
> >> 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=20
> >> splitting the control plane into a separate device is, in=20
> some cases,=20
> >> an attractive design option. So I think this should be=20
> submitted to=20
> >> the Forces working group, or, at least, recast in the Forces=20
> >> framework.
> >> >
> >> >                 jak
> >> >
> >> >> -----Original Message-----
> >> >> From: [email-masked]=20
> >> >> [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
> >> >>
> >> >>
> >> >>
> >> >> Please review and discuss.
> >> >>
> >> >> Thanks,
> >> >>
> >> >> Tom, Alia, Ward
> >> >>
> >> >>
> >> >> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt
> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> irs-discuss mailing list
> >> >> [email-masked]
> >> >> https://www.ietf.org/mailman/listinfo/irs-discuss
> >> >>
> >> > _______________________________________________
> >> > irs-discuss mailing list
> >> > [email-masked]
> >> > https://www.ietf.org/mailman/listinfo/irs-discuss
> >>
> =

Date: Tue, 31 Jul 2012 18:19:54 +0200
From: Robert Raszuk <[email-masked]>
To: Alia Atlas <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS Problem Statement Posted
Reply-To: [email-masked]

Alia,

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

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
> still dealing with the forwarding plane and not the RIBs, IGPs, BGP,
> LDP, RSVP-TE, etc.

And IMHO this is a feature not a bug.

Best regards,
R.

Date: Tue, 31 Jul 2012 18:16:36 +0200
From: Robert Raszuk <[email-masked]>
To: [email-masked]
Subject: Re: [irs-discuss] IRS Problem Statement Posted
Reply-To: [email-masked]

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.

Date: Tue, 31 Jul 2012 12:16:33 -0400
From: Alia Atlas <[email-masked]>
To: James Kempf <[email-masked]>
Cc: Thomas Nadeau <[email-masked]>, Nitin Bahadur <[email-masked]>, Susan Hares <[email-masked]>, Robert Raszuk <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS Problem Statement Posted

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

On Tue, Jul 31, 2012 at 12:11 PM, James Kempf <[email-masked]> wr=
ote:
>
>> [ 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 i=
t running in the meantime. :-)
>
>> [ / 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 ]
>
> 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 middleb=
oxes (complaints about DPI please to /dev/null)
>
> - run a 3GPP/LTE mobile core with the control plane including routing com=
pletely in a cloud instead of only the mobility mangement part
>
> - and finally, as Google has demonstrated, run your network at 90% capaci=
ty 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 wha=
t you can do)
>
>
> But it is not magic, there are lots of problems that need work, and it co=
uld 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 c=
ourse the hype curve moves up another notch.
>
>                         jak
>
>> Thanks
>> Nitin
>>
>> On Jul 30, 2012, at 6:48 PM, "Robert Raszuk"
>> <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss

From: James Kempf <[email-masked]>
To: Nitin Bahadur <[email-masked]>, Robert Raszuk <[email-masked]>
Date: Tue, 31 Jul 2012 12:11:37 -0400
Accept-Language: en-US
acceptlanguage: en-US
Cc: Thomas Nadeau <[email-masked]>, Susan Hares <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS Problem Statement Posted

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

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 w=
ith fixes. And have to hire high priced BFG gurus to configure and keep it =
running in the meantime. :-)=20

> [ / off-topic ]
>=20
> Openflow abstractions are at the forwarding level. IRS does=20
> not compete with that.
>=20
> [ rant ]
> Did I just hear that you've convinced your company to replace=20
> all of its networking gear with OF gear and a uber powerful=20
> controller.
> [ / rant ]

Wollen Sie dann weiter die Unterhaltung auf Deutsch haben?
>=20

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

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

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

- run a 3GPP/LTE mobile core with the control plane including routing compl=
etely 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 an=
d 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 coul=
d still go badly wrong. Right now, it is at the peak of the Gardner hype cu=
rve, give it another year, and everybody will be trashing it, unless of cou=
rse the hype curve moves up another notch.

			jak

> Thanks
> Nitin
>=20
> On Jul 30, 2012, at 6:48 PM, "Robert Raszuk"=20
> <[email-masked]> wrote:
>=20
> > hi Nitin,
> >=20
> >=20
> >> So IRS needs to define interfaces for both the lower layer=20
> and the upper layer.
> >=20
> > That's precisely what openflow protocol does. Thx for=20
> confirming clearly the intentions ;).
> >=20
> > Best regards,
> > R.
> =

From: James Kempf <[email-masked]>
To: Robert Raszuk <[email-masked]>, Alia Atlas <[email-masked]>
Date: Tue, 31 Jul 2012 11:59:51 -0400
Accept-Language: en-US
acceptlanguage: en-US
Cc: Thomas Nadeau <[email-masked]>, Nitin Bahadur <[email-masked]>, Susan Hares <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS Problem Statement Posted

=20
=20
> Alia,
>=20
>=20
> > Hi Rob,
> >=20
> > On the lower layer, Openflow talks to control/specify the=20
> forwarding=20
> > plane - heading towards forwarding plane modeling; something that=20
> > ForCES did a while ago.  It focuses on Layer-2 and does not=20
> interact=20
> > with the routing control plane - generally assuming that the routing
> > control protocol does not/should not exist.  =20
>=20
>=20
> Completely incorrect assumption sorry. OF does not assume L2=20
> as an example I have been working on routing applications=20
> over OF based data plane for over a year now.
>=20
> OF separates control plane including ability to run routing=20
> protocols from forwarding entities. That's the most important point.
>=20
> Hybrid work actually does not help too much .. Especially the=20
> integrated effort. Retrieving state is not a focus as the=20
> assumption is that such state is known in the controller.=20
> However state validation or verification is something that OF=20
> need to pay more attention to - no question.
>=20
> Btw .. If IETF magically does something to equipment vendors=20
> so they will ship FORCEs enabled platforms I am all game.=20
> That would be productive. IRS as of now is more to mud the=20
> water then to come with an alternative to Forces or OF.
>=20

Agree.

		jak

> Best regards,
> R.
>=20
>=20
>=20
> > Yes, there is nascent
> > work on hybrid OpenFlow switches - but that is very far=20
> from a model=20
> > based on USING the router's OS and routing capabilities and handling
> > multiple applications installing state.   Retrieving state=20
> is also not
> > a focus in Openflow.
> >=20
> > On the upper layer, ONF is starting to tentatively talk about=20
> > northbound APIs - which are from OpenFlow controllers up towards=20
> > orchestrators or applications.
> >=20
> > I  don't, personally, think that IRS should cover the latter upper=20
> > layer - though a translation layer and thinking through the=20
> network OS=20
> > abstractions is certainly interesting and part of the ecosystem.
> >=20
> > Would you care to clearly clarify your concerns and=20
> assumptions about=20
> > intentions?
> >=20
> > The two drafts work at defining what IRS should be; I think=20
> that there=20
> > is a clear difference in approach and intended functionality from=20
> > OpenFlow.
> >=20
> > Surely you aren't suggesting that the IETF should not do=20
> anything in=20
> > this space because OpenFlow might get around to it someday?
> >=20
> > Alia
> >=20
> > On Mon, Jul 30, 2012 at 9:48 PM, Robert Raszuk=20
> <[email-masked]> wrote:
> >> hi Nitin,
> >>=20
> >>=20
> >>> So IRS needs to define interfaces for both the lower=20
> layer and the upper layer.
> >>=20
> >> That's precisely what openflow protocol does. Thx for=20
> confirming clearly the intentions ;).
> >>=20
> >> Best regards,
> >> R.
> >> _______________________________________________
> >> irs-discuss mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/irs-discuss
> > _______________________________________________
> > irs-discuss mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/irs-discuss
> =

Date: Tue, 31 Jul 2012 16:49:30 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Subject: [irs-discuss] IRS problem statement and NETCONF/YANG
Reply-To: Juergen Schoenwaelder <[email-masked]>

Hi,

reading through the problem statement posted at

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

I noticed a number of statements concerning NETCONF and YANG that
probably need to be corrected. For more background where NETCONF and
YANG is, you may want to consult the tutorial slides posted at

http://cnds.eecs.jacobs-university.de/slides/2012-ietf-84-netconf-yang.pdf

and consult the documents referenced in the slides. Some more detailed
comments:

:   Finally, the IETF's Network Configuration (or NetConf) protocol has
:   made many strides at overcoming most of the limitations around
:   configuration that were just described.  However, the lack of
:   standard data models have hampered the adoption of NetConf.

The NETMOD working group has been chartered to work on common core
data models and currently has core data models for the configuration
of network interfaces, ip interfaces and a core routing configuration
data model in WG last call:

http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-04
http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-05
http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-05

:   While NetConf has solved many of the deficiencies present in SNMP in
:   terms of configuration, it still does not satisfy a number of
:   requirements needed to manage today's routing information.  First,
:   the lack of standard data models have hampered the adoption of
:   NetConf; a significant amount of per-vendor customization is still
:   needed.  The transport mechanisms that are currently defined (e.g.,
:   SOAP/BEEP) for NetConf are not those commonly used by modern
:   applications (e.g., ReST or JSON).

The default to implement transport for NETCONF is SSH. There is
another transport over TLS. The BEEP and SOAP transports are on their
way to be declared historic. That said, there is work underway to
define a JSON / REST API to YANG modelled NETCONF data stores. 

http://tools.ietf.org/html/draft-bierman-netconf-yang-api-00
http://tools.ietf.org/html/draft-lhotka-yang-json-00

:   NetConf primarily facilitates configuration rather than reading of
:   state or handling asynchronous events.

Not sure what primarily facilitates means but NETCONF does support all
three functions. NETCONF allows read access to all existing SNMP
instrumentation of devices.

:   NetConf matches up to the key needed aspects as follows
:
:   Multiple Simultaneous Asynchronous Operations:   Not Possible

The NETCONF protocol tags RPC invocations with a message-id that is
echoed back in RPC replies, allowing asynchronous operations. NETCONF
also provides global and partial locks to properly deal concurrent
operations received via multiple channels.

:   Configuration Not Re-Processed:   Not Possible

I simply do not understand the definition of this aspect. You document
says:

:   Configuration Not Re-Processed:   When an IRS operation is processed,
:      it does not require that any of the configuration be processed.
:      I.e., the desired behavior is orthogonal to the static
:      configuration.

A clarficiation is needed what you mean with this. Anyway, NETCONF
distinguishes between different configuration data stores. If you want
to distinguish between changes that affect only the current behaviour
but not say the next startup behaviour (i.e. the changes do not
persist), then this is already supported by NETCONF.

Perhaps your concern is that making a change requires to reprocess the
whole configuration? In that case, this is clearly not required
anywhere by the NETCONF protocol specification. In fact, the
edit-config operation allows to send detailed configuration change
sets to a NETCONF server.

:   Duplex:   Not Possible - strict pull model.

NETCONF does have support for event notifications that are pushed by
the device. The initiation of the session is client to server for the
existing transports - but this is mostly a property of the transports.
Some vendors use non-standard extensions for the SSH transport to
support device initiated sessions.

:   High-Throughput:   Unlikely - Can depend on configuration size

Well, this is ill defined in the first place. Your definition is:

:   High-Throughput:   At a minimum, the IRS Agent and associated router
:      should be able to handle hundreds of simple operations per second.

So what is a "simple operation"? I am rather optimistic that it is
possible to do some "simple operation" in NETCONF at the requested
speed. To be useful, you really need to be more precise.

:   Responsive:   Unlikely - Can depend on configuration size

Again, this is under specified. Your definition is:

:   Responsive:   It should be possible to complete simple operations
:      within a sub-second time-scale.

I am sure NETCONF servers easily respond within a sub-second
time-scale. We have several implementors here at the IETF, I
am sure they can provide more concrete information about the
efficiency aspects.

:   Multi-Channel:   Not Possible

NETCONF allows to use multiple SSH or TLS sessions (hence multiple TCP
sessions) and it provides the needed coordination primitives. In
addition, the SSH transport can be used to run multiple SSH channels
multiplexed over a single TCP session.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

From: "UTTARO, JAMES" <[email-masked]>
To: "'Alia Atlas'" <[email-masked]>, Robert Raszuk <[email-masked]>
Date: Tue, 31 Jul 2012 14:10:06 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS Problem Statement Posted

IMO the ability to manipulate routing state, context, etc... is what IRS br=
ings 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

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 <[email-masked]> 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 <[email-masked]> 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 examp=
le 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 fr=
om 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 sta=
te 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 wil=
l ship FORCEs enabled platforms I am all game. That would be productive. IR=
S as of now is more to mud the water then to come with an alternative to Fo=
rces 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 <[email-masked]> wrot=
e:
>>>> hi Nitin,
>>>>
>>>>
>>>>> So IRS needs to define interfaces for both the lower layer and the up=
per layer.
>>>>
>>>> That's precisely what openflow protocol does. Thx for confirming clear=
ly the intentions ;).
>>>>
>>>> Best regards,
>>>> R.
>>>> _______________________________________________
>>>> irs-discuss mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
_______________________________________________
irs-discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/irs-discuss

Date: Tue, 31 Jul 2012 09:44:58 -0400
From: Alia Atlas <[email-masked]>
To: Robert Raszuk <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
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 <[email-masked]> 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 <[email-masked]> 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 examp=
le 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 fr=
om 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 sta=
te 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 wil=
l ship FORCEs enabled platforms I am all game. That would be productive. IR=
S as of now is more to mud the water then to come with an alternative to Fo=
rces 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 <[email-masked]> wrot=
e:
>>>> hi Nitin,
>>>>
>>>>
>>>>> So IRS needs to define interfaces for both the lower layer and the up=
per layer.
>>>>
>>>> That's precisely what openflow protocol does. Thx for confirming clear=
ly the intentions ;).
>>>>
>>>> Best regards,
>>>> R.
>>>> _______________________________________________
>>>> irs-discuss mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/irs-discuss

Date: Mon, 30 Jul 2012 22:22:52 -0400
From: Alia Atlas <[email-masked]>
To: Robert Raszuk <[email-masked]>
Cc: Thomas Nadeau <[email-masked]>, Nitin Bahadur <[email-masked]>, Susan Hares <[email-masked]>, James Kempf <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: 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 <[email-masked]> 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 exampl=
e 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 fro=
m 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 stat=
e is known in the controller. However state validation or verification is s=
omething 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 For=
ces 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 <[email-masked]> wrote=
:
>>> hi Nitin,
>>>
>>>
>>>> So IRS needs to define interfaces for both the lower layer and the upp=
er layer.
>>>
>>> That's precisely what openflow protocol does. Thx for confirming clearl=
y the intentions ;).
>>>
>>> Best regards,
>>> R.
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss

From: Thomas Nadeau <[email-masked]>
To: Gert Grammel <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 30 Jul 2012 22:08:32 -0400
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

	That is correct; it is not our intent to reinvent SNMP or anything else.

	--Tom

On 7/30/12 7:05 PM, "Gert Grammel" <[email-masked]> wrote:

>Alia,
>
>My point was not about the abbreviation. It was about positioning IRS.
>In the end IRS is not yet another MIB nor just another IGP extension.
>
>Gert=20
>
>
>
>
>----- Original Message -----
>From: Alia Atlas <[email-masked]>
>To: Gert Grammel
>Cc: [email-masked] <[email-masked]>
>Sent: Tue Jul 31 02:44:35 2012
>Subject: Re: [irs-discuss] IRS comments
>
>We can consider other namings, whether NPP or RSI or other suggestions.
>
>I think we still have a bit of time and discussion for the
>requirements before we have to finalize that.
>
>Alia
>
>On Mon, Jul 30, 2012 at 9:40 PM, Gert Grammel <[email-masked]>
>wrote:
>> Tom,
>>
>> It is confusing to understand whether IRS belongs to a new network
>>management plane or if it's more of a control plane extension. The draft
>>wisely avoids this classification.
>> To me IRS appears to be a completely different beast which should best
>>be  characterized as 'Network Programming Plane' NPP.
>> It neither aims to do full provisioning (as a management plane would
>>do) nor aims to replace routing (as a control plane would do).
>> Hence we better name the baby NPP -- thereby avoiding any linkage to
>>taxation.
>>
>>
>> Gert
>>
>>
>>
>>
>> ----- Original Message -----
>> From: [email-masked] <[email-masked]>
>> To: Lenny Giuliano; Alia Atlas
>> Cc: [email-masked] <[email-masked]>
>> Sent: Tue Jul 31 01:50:40 2012
>> Subject: Re: [irs-discuss] IRS comments
>>
>>
>> [Re-adding IRS]
>>
>>         Thank you for reviewing and the comments. We will incorporate
>>the edits
>> in the next rev.
>>
>>         --Tom
>>
>>
>> On 7/30/12 5:04 PM, "Lenny Giuliano" <[email-masked]> wrote:
>>
>>>
>>>Minor points:
>>>
>>>-section 4, para 2, 3rd sentence, "Howeve,r"
>>>
>>>-4.1.3 "There is no bidirectional programmatic interface to add, modify,
>>>    remove or read state from the multicast RIB."
>>>       -How is this unique to mcast?  Couldn't you say the same thing
>>>       about unicast?
>>>
>>>-4.1.3 "The multicast state added need not match to well-known protocol
>>>    installed state.  For instance, traffic received on an specified
>>>set,
>>>    or all, interfaces that is destined to a particular prefix from all
>>>    sources or a particular prefix could be subject to the specified
>>>    replication."
>>>       -Not clear to me at all what this para is saying.
>>>
>>>-"IRS"- you may want to select a different acronym that isn't related to
>>>something as unpopular as taxation (something we learned with AMT).
>>>Maybe
>>>RSI instead...
>>>
>>>Overall, I found the doc to be clearly written and straightforward.
>>>Sounds like Openflow for routers.  Not sure if it's intentional that you
>>>didn't mention Openflow, but it did seem like an elephant in the room as
>>>I
>>>was reading thru.  Also, I did wonder what was new and novel here, as
>>>this
>>>sounded like our SDK which has been around for years.
>>>
>>>
>>>-Lenny
>>
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>_______________________________________________
>irs-discuss mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/irs-discuss

Date: Mon, 30 Jul 2012 22:11:59 -0400
From: Alia Atlas <[email-masked]>
To: Gert Grammel <[email-masked]>
Cc: [email-masked]
Subject: Re: [irs-discuss] IRS comments

I do agree - and trying to describe IRS can be hard because of
confusion as to whether it is a configuration protocol or ...

It's really to support programmable networks - I rather like the idea
of describing it as Network Programming Plane...

Alia

On Mon, Jul 30, 2012 at 10:05 PM, Gert Grammel <[email-masked]> wrote:
> Alia,
>
> My point was not about the abbreviation. It was about positioning IRS.
> In the end IRS is not yet another MIB nor just another IGP extension.
>
> Gert
>
>
>
>
> ----- Original Message -----
> From: Alia Atlas <[email-masked]>
> To: Gert Grammel
> Cc: [email-masked] <[email-masked]>
> Sent: Tue Jul 31 02:44:35 2012
> Subject: Re: [irs-discuss] IRS comments
>
> We can consider other namings, whether NPP or RSI or other suggestions.
>
> I think we still have a bit of time and discussion for the
> requirements before we have to finalize that.
>
> Alia
>
> On Mon, Jul 30, 2012 at 9:40 PM, Gert Grammel <[email-masked]> wrote:
>> Tom,
>>
>> It is confusing to understand whether IRS belongs to a new network management plane or if it's more of a control plane extension. The draft wisely avoids this classification.
>> To me IRS appears to be a completely different beast which should best be  characterized as 'Network Programming Plane' NPP.
>> It neither aims to do full provisioning (as a management plane would do) nor aims to replace routing (as a control plane would do).
>> Hence we better name the baby NPP -- thereby avoiding any linkage to taxation.
>>
>>
>> Gert
>>
>>
>>
>>
>> ----- Original Message -----
>> From: [email-masked] <[email-masked]>
>> To: Lenny Giuliano; Alia Atlas
>> Cc: [email-masked] <[email-masked]>
>> Sent: Tue Jul 31 01:50:40 2012
>> Subject: Re: [irs-discuss] IRS comments
>>
>>
>> [Re-adding IRS]
>>
>>         Thank you for reviewing and the comments. We will incorporate the edits
>> in the next rev.
>>
>>         --Tom
>>
>>
>> On 7/30/12 5:04 PM, "Lenny Giuliano" <[email-masked]> wrote:
>>
>>>
>>>Minor points:
>>>
>>>-section 4, para 2, 3rd sentence, "Howeve,r"
>>>
>>>-4.1.3 "There is no bidirectional programmatic interface to add, modify,
>>>    remove or read state from the multicast RIB."
>>>       -How is this unique to mcast?  Couldn't you say the same thing
>>>       about unicast?
>>>
>>>-4.1.3 "The multicast state added need not match to well-known protocol
>>>    installed state.  For instance, traffic received on an specified set,
>>>    or all, interfaces that is destined to a particular prefix from all
>>>    sources or a particular prefix could be subject to the specified
>>>    replication."
>>>       -Not clear to me at all what this para is saying.
>>>
>>>-"IRS"- you may want to select a different acronym that isn't related to
>>>something as unpopular as taxation (something we learned with AMT).
>>>Maybe
>>>RSI instead...
>>>
>>>Overall, I found the doc to be clearly written and straightforward.
>>>Sounds like Openflow for routers.  Not sure if it's intentional that you
>>>didn't mention Openflow, but it did seem like an elephant in the room as
>>>I
>>>was reading thru.  Also, I did wonder what was new and novel here, as
>>>this
>>>sounded like our SDK which has been around for years.
>>>
>>>
>>>-Lenny
>>
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss

From: Robert Raszuk <[email-masked]>
Date: Mon, 30 Jul 2012 19:10:49 -0700
To: Nitin Bahadur <[email-masked]>
Cc: Thomas Nadeau <[email-masked]>, James Kempf <[email-masked]>, Susan Hares <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS Problem Statement Posted

> [ off-topic ]
>=20
> 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=
.
>=20

No

> [ / off-topic ]
>=20
> Openflow abstractions are at the forwarding level. IRS does not compete wi=
th that.
>=20
> [ rant ]
> Did I just hear that you've convinced your company to replace all of its n=
etworking gear with OF gear and a uber powerful controller.
> [ / rant ]

No

Thx,
R.

>=20
> Thanks
> Nitin
>=20
> On Jul 30, 2012, at 6:48 PM, "Robert Raszuk" <[email-masked]> wrote:
>=20
>> hi Nitin,
>>=20
>>=20
>>> So IRS needs to define interfaces for both the lower layer and the upper=
 layer.
>>=20
>> That's precisely what openflow protocol does. Thx for confirming clearly t=
he intentions ;).
>>=20
>> Best regards,
>> R.

From: Robert Raszuk <[email-masked]>
Date: Mon, 30 Jul 2012 19:09:09 -0700
To: Alia Atlas <[email-masked]>
Cc: Thomas Nadeau <[email-masked]>, Nitin Bahadur <[email-masked]>, Susan Hares <[email-masked]>, James Kempf <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS Problem Statement Posted

Alia,

> Hi Rob,
>=20
> 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.  =20

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 f=
orwarding entities. That's the most important point.

Hybrid work actually does not help too much .. Especially the integrated eff=
ort. Retrieving state is not a focus as the assumption is that such state is=
 known in the controller. However state validation or verification is someth=
ing that OF need to pay more attention to - no question.

Btw .. If IETF magically does something to equipment vendors so they will sh=
ip FORCEs enabled platforms I am all game. That would be productive. IRS as o=
f 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.
>=20
> On the upper layer, ONF is starting to tentatively talk about
> northbound APIs - which are from OpenFlow controllers up towards
> orchestrators or applications.
>=20
> 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.
>=20
> Would you care to clearly clarify your concerns and assumptions about
> intentions?
>=20
> 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.
>=20
> Surely you aren't suggesting that the IETF should not do anything in
> this space because OpenFlow might get around to it someday?
>=20
> Alia
>=20
> On Mon, Jul 30, 2012 at 9:48 PM, Robert Raszuk <[email-masked]> wrote:
>> hi Nitin,
>>=20
>>=20
>>> So IRS needs to define interfaces for both the lower layer and the upper=
 layer.
>>=20
>> That's precisely what openflow protocol does. Thx for confirming clearly t=
he intentions ;).
>>=20
>> Best regards,
>> R.
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss

Content-Class: urn:content-classes:message
Date: Tue, 31 Jul 2012 03:05:18 +0100
From: Gert Grammel <[email-masked]>
To: <[email-masked]>
Cc: [email-masked]
Subject: Re: [irs-discuss] IRS comments

Alia,

My point was not about the abbreviation. It was about positioning IRS.=20
In the end IRS is not yet another MIB nor just another IGP extension.

Gert=20

----- Original Message -----
From: Alia Atlas <[email-masked]>
To: Gert Grammel
Cc: [email-masked] <[email-masked]>
Sent: Tue Jul 31 02:44:35 2012
Subject: Re: [irs-discuss] IRS comments

We can consider other namings, whether NPP or RSI or other suggestions.

I think we still have a bit of time and discussion for the
requirements before we have to finalize that.

Alia

On Mon, Jul 30, 2012 at 9:40 PM, Gert Grammel <[email-masked]> =
wrote:
> Tom,
>
> It is confusing to understand whether IRS belongs to a new network =
management plane or if it's more of a control plane extension. The draft =
wisely avoids this classification.
> To me IRS appears to be a completely different beast which should best =
be  characterized as 'Network Programming Plane' NPP.
> It neither aims to do full provisioning (as a management plane would =
do) nor aims to replace routing (as a control plane would do).
> Hence we better name the baby NPP -- thereby avoiding any linkage to =
taxation.
>
>
> Gert
>
>
>
>
> ----- Original Message -----
> From: [email-masked] <[email-masked]>
> To: Lenny Giuliano; Alia Atlas
> Cc: [email-masked] <[email-masked]>
> Sent: Tue Jul 31 01:50:40 2012
> Subject: Re: [irs-discuss] IRS comments
>
>
> [Re-adding IRS]
>
>         Thank you for reviewing and the comments. We will incorporate =
the edits
> in the next rev.
>
>         --Tom
>
>
> On 7/30/12 5:04 PM, "Lenny Giuliano" <[email-masked]> wrote:
>
>>
>>Minor points:
>>
>>-section 4, para 2, 3rd sentence, "Howeve,r"
>>
>>-4.1.3 "There is no bidirectional programmatic interface to add, =
modify,
>>    remove or read state from the multicast RIB."
>>       -How is this unique to mcast?  Couldn't you say the same thing
>>       about unicast?
>>
>>-4.1.3 "The multicast state added need not match to well-known =
protocol
>>    installed state.  For instance, traffic received on an specified =
set,
>>    or all, interfaces that is destined to a particular prefix from =
all
>>    sources or a particular prefix could be subject to the specified
>>    replication."
>>       -Not clear to me at all what this para is saying.
>>
>>-"IRS"- you may want to select a different acronym that isn't related =
to
>>something as unpopular as taxation (something we learned with AMT).
>>Maybe
>>RSI instead...
>>
>>Overall, I found the doc to be clearly written and straightforward.
>>Sounds like Openflow for routers.  Not sure if it's intentional that =
you
>>didn't mention Openflow, but it did seem like an elephant in the room =
as
>>I
>>was reading thru.  Also, I did wonder what was new and novel here, as
>>this
>>sounded like our SDK which has been around for years.
>>
>>
>>-Lenny
>
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss

From: Nitin Bahadur <[email-masked]>
To: Robert Raszuk <[email-masked]>
Date: Mon, 30 Jul 2012 19:06:42 -0700
Accept-Language: en-US
acceptlanguage: en-US
Cc: Thomas Nadeau <[email-masked]>, James Kempf <[email-masked]>, Susan Hares <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS Problem Statement Posted

[ 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 wit=
h that.

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

Thanks
Nitin

On Jul 30, 2012, at 6:48 PM, "Robert Raszuk" <[email-masked]> wrote:

> hi Nitin,
>=20
>=20
>> So IRS needs to define interfaces for both the lower layer and the upper=
 layer.
>=20
> That's precisely what openflow protocol does. Thx for confirming clearly =
the intentions ;).
>=20
> Best regards,
> R.

Date: Mon, 30 Jul 2012 21:58:09 -0400
From: Alia Atlas <[email-masked]>
To: Robert Raszuk <[email-masked]>
Cc: Thomas Nadeau <[email-masked]>, Nitin Bahadur <[email-masked]>, Susan Hares <[email-masked]>, James Kempf <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS Problem Statement Posted

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

On Mon, Jul 30, 2012 at 9:48 PM, Robert Raszuk <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss

From: Robert Raszuk <[email-masked]>
Date: Mon, 30 Jul 2012 18:48:06 -0700
To: Nitin Bahadur <[email-masked]>
Cc: Thomas Nadeau <[email-masked]>, James Kempf <[email-masked]>, Susan Hares <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS Problem Statement Posted

hi Nitin,

> So IRS needs to define interfaces for both the lower layer and the upper l=
ayer.

That's precisely what openflow protocol does. Thx for confirming clearly the=
 intentions ;).

Best regards,
R.=

Date: Mon, 30 Jul 2012 21:44:35 -0400
From: Alia Atlas <[email-masked]>
To: Gert Grammel <[email-masked]>
Cc: [email-masked]
Subject: Re: [irs-discuss] IRS comments

We can consider other namings, whether NPP or RSI or other suggestions.

I think we still have a bit of time and discussion for the
requirements before we have to finalize that.

Alia

On Mon, Jul 30, 2012 at 9:40 PM, Gert Grammel <[email-masked]> wrote:
> Tom,
>
> It is confusing to understand whether IRS belongs to a new network management plane or if it's more of a control plane extension. The draft wisely avoids this classification.
> To me IRS appears to be a completely different beast which should best be  characterized as 'Network Programming Plane' NPP.
> It neither aims to do full provisioning (as a management plane would do) nor aims to replace routing (as a control plane would do).
> Hence we better name the baby NPP -- thereby avoiding any linkage to taxation.
>
>
> Gert
>
>
>
>
> ----- Original Message -----
> From: [email-masked] <[email-masked]>
> To: Lenny Giuliano; Alia Atlas
> Cc: [email-masked] <[email-masked]>
> Sent: Tue Jul 31 01:50:40 2012
> Subject: Re: [irs-discuss] IRS comments
>
>
> [Re-adding IRS]
>
>         Thank you for reviewing and the comments. We will incorporate the edits
> in the next rev.
>
>         --Tom
>
>
> On 7/30/12 5:04 PM, "Lenny Giuliano" <[email-masked]> wrote:
>
>>
>>Minor points:
>>
>>-section 4, para 2, 3rd sentence, "Howeve,r"
>>
>>-4.1.3 "There is no bidirectional programmatic interface to add, modify,
>>    remove or read state from the multicast RIB."
>>       -How is this unique to mcast?  Couldn't you say the same thing
>>       about unicast?
>>
>>-4.1.3 "The multicast state added need not match to well-known protocol
>>    installed state.  For instance, traffic received on an specified set,
>>    or all, interfaces that is destined to a particular prefix from all
>>    sources or a particular prefix could be subject to the specified
>>    replication."
>>       -Not clear to me at all what this para is saying.
>>
>>-"IRS"- you may want to select a different acronym that isn't related to
>>something as unpopular as taxation (something we learned with AMT).
>>Maybe
>>RSI instead...
>>
>>Overall, I found the doc to be clearly written and straightforward.
>>Sounds like Openflow for routers.  Not sure if it's intentional that you
>>didn't mention Openflow, but it did seem like an elephant in the room as
>>I
>>was reading thru.  Also, I did wonder what was new and novel here, as
>>this
>>sounded like our SDK which has been around for years.
>>
>>
>>-Lenny
>
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss

Content-Class: urn:content-classes:message
Date: Tue, 31 Jul 2012 02:40:56 +0100
From: Gert Grammel <[email-masked]>
To: Thomas Nadeau <[email-masked]>, Lenny Giuliano <[email-masked]>, Alia Atlas <[email-masked]>
Cc: [email-masked]
Subject: Re: [irs-discuss] IRS comments

Tom,

It is confusing to understand whether IRS belongs to a new network =
management plane or if it's more of a control plane extension. The draft =
wisely avoids this classification.
To me IRS appears to be a completely different beast which should best =
be  characterized as 'Network Programming Plane' NPP.=20
It neither aims to do full provisioning (as a management plane would do) =
nor aims to replace routing (as a control plane would do).
Hence we better name the baby NPP -- thereby avoiding any linkage to =
taxation.

Gert

----- Original Message -----
From: [email-masked] <[email-masked]>
To: Lenny Giuliano; Alia Atlas
Cc: [email-masked] <[email-masked]>
Sent: Tue Jul 31 01:50:40 2012
Subject: Re: [irs-discuss] IRS comments

[Re-adding IRS]

	Thank you for reviewing and the comments. We will incorporate the edits
in the next rev.

	--Tom

On 7/30/12 5:04 PM, "Lenny Giuliano" <[email-masked]> wrote:

>
>Minor points:
>
>-section 4, para 2, 3rd sentence, "Howeve,r"
>
>-4.1.3 "There is no bidirectional programmatic interface to add, =
modify,
>    remove or read state from the multicast RIB."
> 	-How is this unique to mcast?  Couldn't you say the same thing
> 	about unicast?
>
>-4.1.3 "The multicast state added need not match to well-known protocol
>    installed state.  For instance, traffic received on an specified =
set,
>    or all, interfaces that is destined to a particular prefix from all
>    sources or a particular prefix could be subject to the specified
>    replication."
> 	-Not clear to me at all what this para is saying.
>
>-"IRS"- you may want to select a different acronym that isn't related =
to
>something as unpopular as taxation (something we learned with AMT).
>Maybe=20
>RSI instead...
>
>Overall, I found the doc to be clearly written and straightforward.
>Sounds like Openflow for routers.  Not sure if it's intentional that =
you
>didn't mention Openflow, but it did seem like an elephant in the room =
as
>I=20
>was reading thru.  Also, I did wonder what was new and novel here, as
>this=20
>sounded like our SDK which has been around for years.
>
>
>-Lenny

_______________________________________________
irs-discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/irs-discuss

Date: Mon, 30 Jul 2012 21:39:35 -0400
From: Alia Atlas <[email-masked]>
To: Susan Hares <[email-masked]>
Cc: Thomas Nadeau <[email-masked]>, Nitin Bahadur <[email-masked]>, James Kempf <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS Problem Statement Posted

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

On Mon, Jul 30, 2012 at 9:24 PM, Susan Hares <[email-masked]> wrote=
:
> Nitin:
>
> Exposing some network intelligence can either be done in detail or in som=
e amount of summarization.
> If you are doing detail, you have bandwidth issues. If you are doing summ=
arization 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 det=
ails - just the fact they can get from point A to Point B (or for multi-cas=
t 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 o=
f 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,
>
> This is not about splitting control plane and forwarding plane. It is abo=
ut exposing network intelligence in the network elements to an external con=
troller.
> And it is about allowing an external controller to use that information f=
or 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 req=
uest/response gated mechanism.
>
> Hope that helps.
>
> Thanks
> Nitin
>
> On 7/30/12 3:11 PM, "James Kempf" <[email-masked]> wrote:
>
> 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 fr=
amework explicitedly designed for device to controller communication. Its m=
ajor 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 stat=
e update. Forces has already established that splitting the control plane i=
nto 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, r=
ecast 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
>>
>>
>>
>> Please review and discuss.
>>
>> Thanks,
>>
>> Tom, Alia, Ward
>>
>>
>> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt
>>
>>
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
>
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss

From: Nitin Bahadur <[email-masked]>
To: Susan Hares <[email-masked]>
Date: Mon, 30 Jul 2012 18:39:07 -0700
Accept-Language: en-US
acceptlanguage: en-US
Cc: Thomas Nadeau <[email-masked]>, James Kempf <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS Problem Statement Posted

Hi Susan,

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

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 elemen=
ts and programs the network elements.

And the middle layer is the business layer that takes user input from north=
bound 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 la=
yer.

Thanks
Nitin

On Jul 30, 2012, at 6:27 PM, "Susan Hares" <[email-masked]> wrote:

> Nitin:=20
>=20
> Exposing some network intelligence can either be done in detail or in som=
e amount of summarization.=20
> If you are doing detail, you have bandwidth issues. If you are doing summ=
arization or opacity, you are talking about layers of information.=20
>=20
> Apps need to find out what they need to get. They do not need all the det=
ails - just the fact they can get from point A to Point B (or for multi-cas=
t 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. =20
>=20
> The network orchestration then serves to be the paths to the place to eat=
.  This can either be distributed or centralized. =20
>=20
> If we have an Interface to routing, it need to have a two-layer concept o=
f exposing information. =20
>=20
> Sue Hares=20
>=20
> -----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
>=20
> Hi James,
>=20
> This is not about splitting control plane and forwarding plane. It is abo=
ut exposing network intelligence in the network elements to an external con=
troller.
> And it is about allowing an external controller to use that information f=
or enabling network-aware apps. And it is about allowing apps to influence =
the
> network element's RIB (not the FIB directly).
>=20
> Streaming is essential to allow for operations at scale...and avoid a req=
uest/response gated mechanism.
>=20
> Hope that helps.
>=20
> Thanks
> Nitin
>=20
> On 7/30/12 3:11 PM, "James Kempf" <[email-masked]> wrote:
>=20
> 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 fr=
amework explicitedly designed for device to controller communication. Its m=
ajor 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.
>=20
> I don't think it is necessary to have a problem statement for router stat=
e update. Forces has already established that splitting the control plane i=
nto 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, r=
ecast in the Forces framework.
>=20
>                jak
>=20
>> -----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
>>=20
>>=20
>>=20
>> Please review and discuss.
>>=20
>> Thanks,
>>=20
>> Tom, Alia, Ward
>>=20
>>=20
>> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt
>>=20
>>=20
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>=20
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
>=20
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss

Date: Mon, 30 Jul 2012 21:33:10 -0400
From: Alia Atlas <[email-masked]>
To: Susan Hares <[email-masked]>
Cc: "Joel M. Halpern" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt

Hi Sue,

On Mon, Jul 30, 2012 at 9:16 PM, Susan Hares <[email-masked]> wrote=
:
> Joel and irs-folks:
>
> +1 on Joel.
>
>  Beyond your comments, the requirement prioritization of the interworking=
 of these interfaces is not clearly delineated in this work. This type of p=
rioritization and sequencing is key to multi-interfaces operation on the mo=
nitoring, configuration or insertion of information into the depth.

[Alia] Can you further clarify, maybe with an example, which aspect
you are thinking of?   Do you mean the ability of an application to
access multiple sub-interfaces?  The interaction of operations
requested by differerent applications?

> In addition, if you are going to do configuration with roll-forward/roll-=
back - you need a transaction based processing.

[Alia] I'm pretty sure that I avoided the word "transaction" in both
drafts.  That was deliberate.  Of course, we can have a discussion
about whether or not some form of transactions might be desirable.  I
am concerned about their potentially heavy-weight nature.

> Therefore, you've skipped even requiring the hard problems.

[Alia] Can I optimistically pretend that means that the requirements
we do have don't seem too hard?  For the responsiveness and throughput
goals, I've put a stake in the ground to avoid transaction-based
semantics.  Naturally, the hordes can run over that stake, if
necessary.

[Alia] For the interaction between different layers of sub-interfaces,
I've been assuming that we'll define the interactions between the
layers based on how they are generally done.  For instance, perhaps we
standardize the idea of preference value - and then the RIB can pick
the best route based upon those preferences.  For interaction between
different applications, I think there's a mixture of
authorization/authentication to get right plus a good set of events
that an application could register for.

> Is this just the -00.draft?

[Alia] Certainly, I expect that we'll uncover more requirements as we
go along.  As I said, some of this is initially setting parts  out of
scope.

Alia

> Sue
>
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] =
On Behalf Of Joel M. Halpern
> Sent: Monday, July 30, 2012 3:15 PM
> To: [email-masked]
> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt
>
> I am finding this document quite confusing.
>
> The primary confusion is that the document first says that it is about
> information that can not be manipulated with existing systems, and then
> proceeds to give a list of use cases all of which can be manipulated
> with existing systems at a suitable degree of abstraction.
>
> As a lesser confusion, the document says that "streaming" is important,
> but then describes "streaming" as "fast, interactive access."  That is
> not streaming.  And depending upon what one means by interactive, plenty
> of systems provide "fest, interactive access."  I realize the document
> later goes on tot talk about speed and frequency of state updates.   But
> that section simply reasserts the earlier terms withotu better
> description or justification.
>
> Yours,
> Joel
>
> On 7/30/2012 2:08 PM, [email-masked] wrote:
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts direc=
tories.
>>
>>
>>       Title           : Interface to the Routing System Framework
>>       Author(s)       : Alia Atlas
>>                            Thomas Nadeau
>>                            Dave Ward
>>       Filename        : draft-ward-irs-framework-00.txt
>>       Pages           : 21
>>       Date            : 2012-07-30
>>
>> Abstract:
>>     This document describes a framework for a standard, programmatic
>>     interface for full-duplex, streaming state transfer in and out of th=
e
>>     Internet's routing system.  It lists the information that might be
>>     exchanged over the interface, and describes the uses of an interface
>>     to the Internet routing system.
>>
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss

From: Susan Hares <[email-masked]>
To: Thomas Nadeau <[email-masked]>, "Joel M. Halpern" <[email-masked]>
Date: Tue, 31 Jul 2012 01:30:55 +0000
Accept-Language: en-US, zh-CN
Cc: Thomas Nadeau <[email-masked]>, James Kempf <[email-masked]>, Alia Atlas <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS Problem Statement Posted

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 reca=
sting of ONF as ForCES LFB.

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

Sue=20

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

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 F=
orCES.  While the initial design goal was forwarding behavior, the protocol=
 design is such that it is usable over a broad range of abstraction levels.
>=20
> 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 framewor=
k of components that can be used to solve that problem.

> On the other hand, I think that working out the problems and entities tha=
t need to be modeled first (which probably does need a dedicated working gr=
oup), 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 w=
herever appropriate.

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

	--Tom

>=20
> yours,
> Jitl
>=20
> On 7/30/2012 6:27 PM, Alia Atlas wrote:
>> Hi James,
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> Are you suggesting that ForCES should drastically expand its scope?
>>=20
>> 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.
>>=20
>> Alia
>>=20
>> On Mon, Jul 30, 2012 at 6:11 PM, James Kempf <[email-masked]> =
wrote:
>>> 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 tha=
t there are no specified devices. This draft would fill that hole.
>>>=20
>>> I don't think it is necessary to have a problem statement for router st=
ate 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.
>>>=20
>>>                 jak
>>>=20
>>>> -----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
>>>>=20
>>>>=20
>>>>=20
>>>> Please review and discuss.
>>>>=20
>>>> Thanks,
>>>>=20
>>>> Tom, Alia, Ward
>>>>=20
>>>>=20
>>>> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> irs-discuss mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>>=20
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>=20
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
>=20

_______________________________________________
irs-discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/irs-discuss

From: Susan Hares <[email-masked]>
To: Nitin Bahadur <[email-masked]>, James Kempf <[email-masked]>, Thomas Nadeau <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 31 Jul 2012 01:24:39 +0000
Accept-Language: en-US, zh-CN
Subject: Re: [irs-discuss] IRS Problem Statement Posted

Nitin:=20

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

Apps need to find out what they need to get. They do not need all the detai=
ls - 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 ne=
ed a match-maker for the application who determine where the applications s=
hall flow.  Now, if they are smart - like people going out to eat - they pi=
ck several ways go to eat traffic. =20

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

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

Sue Hares=20

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

This is not about splitting control plane and forwarding plane. It is about=
 exposing network intelligence in the network elements to an external contr=
oller.
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 th=
e
network element's RIB (not the FIB directly).

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

Hope that helps.

Thanks
Nitin

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

I don't understand why streaming is specified in this draft. And I don't un=
derstand why this draft isn't put in the Forces framework. Forces is a fram=
ework explicitedly designed for device to controller communication. Its maj=
or drawback it that it is a framework with a hole in the middle, in that th=
ere 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 int=
o a separate device is, in some cases, an attractive design option. So I th=
ink this should be submitted to the Forces working group, or, at least, rec=
ast 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
>
>
>
> Please review and discuss.
>
> Thanks,
>
> Tom, Alia, Ward
>
>
> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt
>
>
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
>
_______________________________________________
irs-discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/irs-discuss

_______________________________________________
irs-discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/irs-discuss

Date: Mon, 30 Jul 2012 21:23:00 -0400
From: Alia Atlas <[email-masked]>
To: Robert Raszuk <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS Problem Statement Posted

Rob,

On Mon, Jul 30, 2012 at 9:11 PM, Robert Raszuk <[email-masked]> wrote:
> 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 go=
od 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 configur=
ation. 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.

[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

> Best Rgs,
> R.
>
>
>
> Sent from my iPad
>
> On Jul 30, 2012, at 5:55 PM, Alia Atlas <[email-masked]> wrote:
>
>> 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
>>
>>
>> On Mon, Jul 30, 2012 at 7:31 PM, Robert Raszuk <[email-masked]> wrote=
:
>>> Tom,
>>>
>>> Yes indeed .. Clearly defining what problem are you trying to solve wou=
ld be greatly helpful.
>>>
>>> Best,
>>> R.
>>>
>>>
>>> Sent from my iPad
>>>
>>> On Jul 30, 2012, at 3:54 PM, Thomas Nadeau <[email-masked]> wr=
ote:
>>>
>>>>
>>>> On Jul 30, 2012:3:39 PM, at 3:39 PM, "Joel M. Halpern" <jmh@joelhalper=
n.com> wrote:
>>>>
>>>>> Alia, I do have to disagree with one aspect of your characterization =
fo ForCES.  While the initial design goal was forwarding behavior, the prot=
ocol design is such that it is usable over a broad range of abstraction lev=
els.
>>>>>
>>>>> 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 fr=
amework 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 workin=
g group), and then worrying about which protocol meets the requirements whe=
n we know what exactly we need.  At that point, the protocol work can be do=
ne wherever appropriate.
>>>>
>>>>   Yes, that is precisely what the goals are right now.
>>>>
>>>>   --Tom
>>>>
>>>>
>>>>>
>>>>> yours,
>>>>> Jitl
>>>>>
>>>>> On 7/30/2012 6:27 PM, Alia Atlas wrote:
>>>>>> 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 th=
e
>>>>>> 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
>>>>>>
>>>>>> On Mon, Jul 30, 2012 at 6:11 PM, James Kempf <[email-masked]=
om> wrote:
>>>>>>> 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 i=
s 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 route=
r state update. Forces has already established that splitting the control p=
lane 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 le=
ast, 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Please review and discuss.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Tom, Alia, Ward
>>>>>>>>
>>>>>>>>
>>>>>>>> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> irs-discuss mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> irs-discuss mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>>>> _______________________________________________
>>>>>> irs-discuss mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>>>>
>>>>> _______________________________________________
>>>>> irs-discuss mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>>>
>>>>
>>>> _______________________________________________
>>>> irs-discuss mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/irs-discuss

From: Susan Hares <[email-masked]>
To: "Joel M. Halpern" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 31 Jul 2012 01:16:14 +0000
Accept-Language: en-US, zh-CN
Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt

Joel and irs-folks:=20

+1 on Joel.

 Beyond your comments, the requirement prioritization of the interworking o=
f these interfaces is not clearly delineated in this work. This type of pri=
oritization and sequencing is key to multi-interfaces operation on the moni=
toring, configuration or insertion of information into the depth.

In addition, if you are going to do configuration with roll-forward/roll-ba=
ck - you need a transaction based processing. =20

Therefore, you've skipped even requiring the hard problems.=20

Is this just the -00.draft?=20

Sue=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On=
 Behalf Of Joel M. Halpern
Sent: Monday, July 30, 2012 3:15 PM
To: [email-masked]
Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt

I am finding this document quite confusing.

The primary confusion is that the document first says that it is about=20
information that can not be manipulated with existing systems, and then=20
proceeds to give a list of use cases all of which can be manipulated=20
with existing systems at a suitable degree of abstraction.

As a lesser confusion, the document says that "streaming" is important,=20
but then describes "streaming" as "fast, interactive access."  That is=20
not streaming.  And depending upon what one means by interactive, plenty=20
of systems provide "fest, interactive access."  I realize the document=20
later goes on tot talk about speed and frequency of state updates.   But=20
that section simply reasserts the earlier terms withotu better=20
description or justification.

Yours,
Joel

On 7/30/2012 2:08 PM, [email-masked] wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
>
>
> 	Title           : Interface to the Routing System Framework
> 	Author(s)       : Alia Atlas
>                            Thomas Nadeau
>                            Dave Ward
> 	Filename        : draft-ward-irs-framework-00.txt
> 	Pages           : 21
> 	Date            : 2012-07-30
>
> Abstract:
>     This document describes a framework for a standard, programmatic
>     interface for full-duplex, streaming state transfer in and out of the
>     Internet's routing system.  It lists the information that might be
>     exchanged over the interface, and describes the uses of an interface
>     to the Internet routing system.
>
_______________________________________________
irs-discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/irs-discuss

From: Robert Raszuk <[email-masked]>
Date: Mon, 30 Jul 2012 18:11:16 -0700
To: Alia Atlas <[email-masked]>
Cc: Thomas Nadeau <[email-masked]>, James Kempf <[email-masked]>, "Joel M. Halpern" <[email-masked]>, "[email-masked]" <[email-masked]>, Thomas Nadeau <[email-masked]>
Subject: Re: [irs-discuss] IRS Problem Statement Posted

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

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 loo=
ks like it is the latter.

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

Best Rgs,
R.

Sent from my iPad

On Jul 30, 2012, at 5:55 PM, Alia Atlas <[email-masked]> wrote:

> Rob,
>=20
> 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.
>=20
> Describing an elephant for the first time is always tricky.
>=20
> Perhaps you could describe your perspective on the problem and what
> you think is unclear.
>=20
> Regards,
> Alia
>=20
>=20
> On Mon, Jul 30, 2012 at 7:31 PM, Robert Raszuk <[email-masked]> wrote:
>> Tom,
>>=20
>> Yes indeed .. Clearly defining what problem are you trying to solve would=
 be greatly helpful.
>>=20
>> Best,
>> R.
>>=20
>>=20
>> Sent from my iPad
>>=20
>> On Jul 30, 2012, at 3:54 PM, Thomas Nadeau <[email-masked]> wrot=
e:
>>=20
>>>=20
>>> On Jul 30, 2012:3:39 PM, at 3:39 PM, "Joel M. Halpern" <jmh@joelhalpern.=
com> wrote:
>>>=20
>>>> Alia, I do have to disagree with one aspect of your characterization fo=
 ForCES.  While the initial design goal was forwarding behavior, the protoco=
l design is such that it is usable over a broad range of abstraction levels.=

>>>>=20
>>>> Similarly, depending upon exactly what we need, netconf + Netmad/YANG m=
ay be suitable / useable.
>>>=20
>>>   We are not ruling out any existing solutions, either in whole or in pa=
rt (modified). The goal right now is to define the problem space and a frame=
work of components that can be used to solve that problem.
>>>=20
>>>> On the other hand, I think that working out the problems and entities t=
hat need to be modeled first (which probably does need a dedicated working g=
roup), 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 wh=
erever appropriate.
>>>=20
>>>   Yes, that is precisely what the goals are right now.
>>>=20
>>>   --Tom
>>>=20
>>>=20
>>>>=20
>>>> yours,
>>>> Jitl
>>>>=20
>>>> On 7/30/2012 6:27 PM, Alia Atlas wrote:
>>>>> Hi James,
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> Are you suggesting that ForCES should drastically expand its scope?
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> Alia
>>>>>=20
>>>>> On Mon, Jul 30, 2012 at 6:11 PM, James Kempf <[email-masked]=
> wrote:
>>>>>> I don't understand why streaming is specified in this draft. And I do=
n'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.
>>>>>>=20
>>>>>> I don't think it is necessary to have a problem statement for router s=
tate 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, r=
ecast in the Forces framework.
>>>>>>=20
>>>>>>               jak
>>>>>>=20
>>>>>>> -----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
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> Please review and discuss.
>>>>>>>=20
>>>>>>> Thanks,
>>>>>>>=20
>>>>>>> Tom, Alia, Ward
>>>>>>>=20
>>>>>>>=20
>>>>>>> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt
>>>>>>>=20
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> irs-discuss mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>>>>>=20
>>>>>> _______________________________________________
>>>>>> irs-discuss mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>>> _______________________________________________
>>>>> irs-discuss mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>>>=20
>>>> _______________________________________________
>>>> irs-discuss mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>>=20
>>>=20
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/irs-discuss

Date: Mon, 30 Jul 2012 20:55:30 -0400
From: Alia Atlas <[email-masked]>
To: Robert Raszuk <[email-masked]>
Cc: Thomas Nadeau <[email-masked]>, James Kempf <[email-masked]>, "Joel M. Halpern" <[email-masked]>, "[email-masked]" <[email-masked]>, Thomas Nadeau <[email-masked]>
Subject: Re: [irs-discuss] IRS Problem Statement Posted

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

On Mon, Jul 30, 2012 at 7:31 PM, Robert Raszuk <[email-masked]> wrote:
> Tom,
>
> Yes indeed .. Clearly defining what problem are you trying to solve would=
 be greatly helpful.
>
> Best,
> R.
>
>
> Sent from my iPad
>
> On Jul 30, 2012, at 3:54 PM, Thomas Nadeau <[email-masked]> wrot=
e:
>
>>
>> On Jul 30, 2012:3:39 PM, at 3:39 PM, "Joel M. Halpern" <jmh@joelhalpern.=
com> wrote:
>>
>>> Alia, I do have to disagree with one aspect of your characterization fo=
 ForCES.  While the initial design goal was forwarding behavior, the protoc=
ol design is such that it is usable over a broad range of abstraction level=
s.
>>>
>>> Similarly, depending upon exactly what we need, netconf + Netmad/YANG m=
ay be suitable / useable.
>>
>>    We are not ruling out any existing solutions, either in whole or in p=
art (modified). The goal right now is to define the problem space and a fra=
mework of components that can be used to solve that problem.
>>
>>> On the other hand, I think that working out the problems and entities t=
hat 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
>>
>>
>>>
>>> yours,
>>> Jitl
>>>
>>> On 7/30/2012 6:27 PM, Alia Atlas wrote:
>>>> 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
>>>>
>>>> On Mon, Jul 30, 2012 at 6:11 PM, James Kempf <[email-masked]=
> wrote:
>>>>> I don't understand why streaming is specified in this draft. And I do=
n't understand why this draft isn't put in the Forces framework. Forces is =
a framework explicitedly designed for device to controller communication. I=
ts major drawback it that it is a framework with a hole in the middle, in t=
hat 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 pla=
ne into a separate device is, in some cases, an attractive design option. S=
o I think this should be submitted to the Forces working group, or, at leas=
t, 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
>>>>>>
>>>>>>
>>>>>>
>>>>>> Please review and discuss.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Tom, Alia, Ward
>>>>>>
>>>>>>
>>>>>> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> irs-discuss mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>>>>
>>>>> _______________________________________________
>>>>> irs-discuss mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>> _______________________________________________
>>>> irs-discuss mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>>
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>
>>
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss

Date: Mon, 30 Jul 2012 20:53:21 -0400
From: Alia Atlas <[email-masked]>
To: James Kempf <[email-masked]>
Cc: Thomas Nadeau <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS Problem Statement Posted

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

On Mon, Jul 30, 2012 at 6:48 PM, James Kempf <[email-masked]> wro=
te:
> Hi Alia,
>
> Perhaps you can explain to me the difference between the state involved i=
n "the routing system (FIB, IGPs, BGP, RSVP-TE, etc.)" and the control plan=
e? The last time I looked, these protocols were all involved in routing con=
trol and therefore could reasonably be characterized as components of the c=
ontrol plane, IMHO.
>
>                 jak
>
>> -----Original Message-----
>> 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,
>>
>> 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
>>
>> On Mon, Jul 30, 2012 at 6:11 PM, James Kempf
>> <[email-masked]> wrote:
>> > 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
>> >>
>> >>
>> >>
>> >> Please review and discuss.
>> >>
>> >> Thanks,
>> >>
>> >> Tom, Alia, Ward
>> >>
>> >>
>> >> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt
>> >>
>> >>
>> >> _______________________________________________
>> >> irs-discuss mailing list
>> >> [email-masked]
>> >> https://www.ietf.org/mailman/listinfo/irs-discuss
>> >>
>> > _______________________________________________
>> > irs-discuss mailing list
>> > [email-masked]
>> > https://www.ietf.org/mailman/listinfo/irs-discuss
>>

From: Thomas Nadeau <[email-masked]>
To: Lenny Giuliano <[email-masked]>, Alia Atlas <[email-masked]>
Date: Mon, 30 Jul 2012 20:50:40 -0400
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

[Re-adding IRS]

	Thank you for reviewing and the comments. We will incorporate the edits
in the next rev.

	--Tom

On 7/30/12 5:04 PM, "Lenny Giuliano" <[email-masked]> wrote:

>
>Minor points:
>
>-section 4, para 2, 3rd sentence, "Howeve,r"
>
>-4.1.3 "There is no bidirectional programmatic interface to add, modify,
>    remove or read state from the multicast RIB."
> 	-How is this unique to mcast?  Couldn't you say the same thing
> 	about unicast?
>
>-4.1.3 "The multicast state added need not match to well-known protocol
>    installed state.  For instance, traffic received on an specified set,
>    or all, interfaces that is destined to a particular prefix from all
>    sources or a particular prefix could be subject to the specified
>    replication."
> 	-Not clear to me at all what this para is saying.
>
>-"IRS"- you may want to select a different acronym that isn't related to
>something as unpopular as taxation (something we learned with AMT).
>Maybe=20
>RSI instead...
>
>Overall, I found the doc to be clearly written and straightforward.
>Sounds like Openflow for routers.  Not sure if it's intentional that you
>didn't mention Openflow, but it did seem like an elephant in the room as
>I=20
>was reading thru.  Also, I did wonder what was new and novel here, as
>this=20
>sounded like our SDK which has been around for years.
>
>
>-Lenny

From: Thomas Nadeau <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 30 Jul 2012 20:48:06 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [irs-discuss] IRS Problem Statement Posted

	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
>
>
>> -----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
>>
>>
>>
>> Please review and discuss.
>>
>> Thanks,
>>
>> Tom, Alia, Ward
>>
>>
>> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt
>>
>>
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss

Date: Mon, 30 Jul 2012 20:48:13 -0400
From: Alia Atlas <[email-masked]>
To: "Joel M. Halpern" <[email-masked]>
Cc: Thomas Nadeau <[email-masked]>, James Kempf <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS Problem Statement Posted

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:
> 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
>
>
> On 7/30/2012 6:27 PM, Alia Atlas wrote:
>>
>> 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
>>
>> On Mon, Jul 30, 2012 at 6:11 PM, James Kempf <[email-masked]>
>> wrote:
>>>
>>> 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
>>>>
>>>>
>>>>
>>>> Please review and discuss.
>>>>
>>>> Thanks,
>>>>
>>>> Tom, Alia, Ward
>>>>
>>>>
>>>> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt
>>>>
>>>>
>>>> _______________________________________________
>>>> irs-discuss mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>>
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>
>

Date: Mon, 30 Jul 2012 20:43:12 -0400
From: Alia Atlas <[email-masked]>
To: Vytautas Valancius <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] irs problem statement

Thanks for the pointers - I saw them on the agenda for NetConf as well.

As I said to Joel, we need to agree and focus on agreeing on the
problem-statement and use-cases before trying to pin down particular
protocol(s).

Hearing more feedback though about how well NetConf does or could meet
the needs and suggested requirements is quite interesting.

Alia

On Mon, Jul 30, 2012 at 7:30 PM, Vytautas Valancius <[email-masked]> wrote:
>> URL:             http://www.ietf.org/internet-drafts/draft-atlas-irs-problem-statement-00.txt
>> Status:          http://datatracker.ietf.org/doc/draft-atlas-irs-problem-statement
>> Htmlized:        http://tools.ietf.org/html/draft-atlas-irs-problem-statement-00
>
> Nitpick:
>
> "The transport mechanisms that are currently defined (e.g., SOAP/BEEP)
> for NetConf are not those commonly used by modern applications (e.g.,
> ReST or JSON)."
>
> Technically correct, but, FYI, there is active work going on to make
> NetConf and YANG REST and JSON friendly:
> http://tools.ietf.org/html/draft-bierman-netconf-yang-api-00
> http://tools.ietf.org/html/draft-lhotka-yang-json-00
>
> Regards,
> Valas
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss

From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Date: Tue, 31 Jul 2012 01:31:44 +0200
Accept-Language: de-DE
acceptlanguage: de-DE
Subject: Re: [irs-discuss] IRS Problem Statement Posted

From: Robert Raszuk <[email-masked]>
Date: Mon, 30 Jul 2012 16:31:28 -0700
To: Thomas Nadeau <[email-masked]>
Cc: Alia Atlas <[email-masked]>, Thomas Nadeau <[email-masked]>, James Kempf <[email-masked]>, "Joel M. Halpern" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS Problem Statement Posted

Tom,

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

Best,
R.

Sent from my iPad

On Jul 30, 2012, at 3:54 PM, Thomas Nadeau <[email-masked]> wrote:

>=20
> On Jul 30, 2012:3:39 PM, at 3:39 PM, "Joel M. Halpern" <[email-masked]=
m> wrote:
>=20
>> Alia, I do have to disagree with one aspect of your characterization fo Fo=
rCES.  While the initial design goal was forwarding behavior, the protocol d=
esign is such that it is usable over a broad range of abstraction levels.
>>=20
>> Similarly, depending upon exactly what we need, netconf + Netmad/YANG may=
 be suitable / useable.
>=20
>    We are not ruling out any existing solutions, either in whole or in par=
t (modified). The goal right now is to define the problem space and a framew=
ork of components that can be used to solve that problem.
>=20
>> On the other hand, I think that working out the problems and entities tha=
t need to be modeled first (which probably does need a dedicated working gro=
up), and then worrying about which protocol meets the requirements when we k=
now what exactly we need.  At that point, the protocol work can be done wher=
ever appropriate.
>=20
>    Yes, that is precisely what the goals are right now.
>=20
>    --Tom
>=20
>=20
>>=20
>> yours,
>> Jitl
>>=20
>> On 7/30/2012 6:27 PM, Alia Atlas wrote:
>>> Hi James,
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> Are you suggesting that ForCES should drastically expand its scope?
>>>=20
>>> 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.
>>>=20
>>> Alia
>>>=20
>>> On Mon, Jul 30, 2012 at 6:11 PM, James Kempf <[email-masked]> w=
rote:
>>>> 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 f=
ramework explicitedly designed for device to controller communication. Its m=
ajor drawback it that it is a framework with a hole in the middle, in that t=
here are no specified devices. This draft would fill that hole.
>>>>=20
>>>> I don't think it is necessary to have a problem statement for router st=
ate update. Forces has already established that splitting the control plane i=
nto a separate device is, in some cases, an attractive design option. So I t=
hink this should be submitted to the Forces working group, or, at least, rec=
ast in the Forces framework.
>>>>=20
>>>>                jak
>>>>=20
>>>>> -----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
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> Please review and discuss.
>>>>>=20
>>>>> Thanks,
>>>>>=20
>>>>> Tom, Alia, Ward
>>>>>=20
>>>>>=20
>>>>> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> irs-discuss mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>>>=20
>>>> _______________________________________________
>>>> irs-discuss mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>=20
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>=20
>=20
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss

Date: Mon, 30 Jul 2012 16:30:53 -0700
From: Vytautas Valancius <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] irs problem statement

> URL:             http://www.ietf.org/internet-drafts/draft-atlas-irs-problem-statement-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-atlas-irs-problem-statement
> Htmlized:        http://tools.ietf.org/html/draft-atlas-irs-problem-statement-00

Nitpick:

"The transport mechanisms that are currently defined (e.g., SOAP/BEEP)
for NetConf are not those commonly used by modern applications (e.g.,
ReST or JSON)."

Technically correct, but, FYI, there is active work going on to make
NetConf and YANG REST and JSON friendly:
http://tools.ietf.org/html/draft-bierman-netconf-yang-api-00
http://tools.ietf.org/html/draft-lhotka-yang-json-00

Regards,
Valas

From: Thomas Nadeau <[email-masked]>
Date: Mon, 30 Jul 2012 15:54:02 -0700
To: "Joel M. Halpern" <[email-masked]>
Cc: Thomas Nadeau <[email-masked]>, James Kempf <[email-masked]>, "[email-masked]" <[email-masked]>, Alia Atlas <[email-masked]>
Subject: Re: [irs-discuss] IRS Problem Statement Posted

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

>=20
> yours,
> Jitl
>=20
> On 7/30/2012 6:27 PM, Alia Atlas wrote:
>> Hi James,
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> Are you suggesting that ForCES should drastically expand its scope?
>>=20
>> 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.
>>=20
>> Alia
>>=20
>> On Mon, Jul 30, 2012 at 6:11 PM, James Kempf =
<[email-masked]> wrote:
>>> 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.
>>>=20
>>> 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.
>>>=20
>>>                 jak
>>>=20
>>>> -----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
>>>>=20
>>>>=20
>>>>=20
>>>> Please review and discuss.
>>>>=20
>>>> Thanks,
>>>>=20
>>>> Tom, Alia, Ward
>>>>=20
>>>>=20
>>>> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> irs-discuss mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>>=20
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>=20
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
>=20

From: James Kempf <[email-masked]>
To: Alia Atlas <[email-masked]>
Date: Mon, 30 Jul 2012 18:48:39 -0400
Accept-Language: en-US
acceptlanguage: en-US
Cc: Thomas Nadeau <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS Problem Statement Posted

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 contr=
ol and therefore could reasonably be characterized as components of the con=
trol plane, IMHO.

		jak=20

> -----Original Message-----
> From: Alia Atlas [mailto:[email-masked]]=20
> Sent: Monday, July 30, 2012 3:27 PM
> To: James Kempf
> Cc: Thomas Nadeau; [email-masked]
> Subject: Re: [irs-discuss] IRS Problem Statement Posted
>=20
> Hi James,
>=20
> Thanks for your thoughts.   Streaming (as I've heard) is not as good a
> description of the desired interface attributes as described=20
> in Sec 1.1, the functional overview.
>=20
> 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.
>=20
> Are you suggesting that ForCES should drastically expand its scope?
>=20
> Before we start debating what and whether to expand existing=20
> protocols, I think we need a common understanding of the=20
> problem we're trying to solve and the related framework.
>=20
> Alia
>=20
> On Mon, Jul 30, 2012 at 6:11 PM, James Kempf=20
> <[email-masked]> wrote:
> > I don't understand why streaming is specified in this=20
> draft. And I don't understand why this draft isn't put in the=20
> Forces framework. Forces is a framework explicitedly designed=20
> for device to controller communication. Its major drawback it=20
> that it is a framework with a hole in the middle, in that=20
> there are no specified devices. This draft would fill that hole.
> >
> > I don't think it is necessary to have a problem statement=20
> for router state update. Forces has already established that=20
> splitting the control plane into a separate device is, in=20
> some cases, an attractive design option. So I think this=20
> should be submitted to the Forces working group, or, at=20
> 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
> >>
> >>
> >>
> >> Please review and discuss.
> >>
> >> Thanks,
> >>
> >> Tom, Alia, Ward
> >>
> >>
> >> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt
> >>
> >>
> >> _______________________________________________
> >> irs-discuss mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/irs-discuss
> >>
> > _______________________________________________
> > irs-discuss mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/irs-discuss
> =

Date: Mon, 30 Jul 2012 18:39:48 -0400
From: "Joel M. Halpern" <[email-masked]>
To: Alia Atlas <[email-masked]>
Cc: Thomas Nadeau <[email-masked]>, James Kempf <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS Problem Statement Posted

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

On 7/30/2012 6:27 PM, Alia Atlas wrote:
> 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
>
> On Mon, Jul 30, 2012 at 6:11 PM, James Kempf <[email-masked]> wrote:
>> 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
>>>
>>>
>>>
>>> Please review and discuss.
>>>
>>> Thanks,
>>>
>>> Tom, Alia, Ward
>>>
>>>
>>> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt
>>>
>>>
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
>

Date: Mon, 30 Jul 2012 18:33:55 -0400
From: "Joel M. Halpern" <[email-masked]>
To: Alia Atlas <[email-masked]>
Cc: [email-masked]
Subject: Re: [irs-discuss] draft-ward-irs-framework

Sounds good.  Thank you.
Joel

On 7/30/2012 6:19 PM, Alia Atlas wrote:
> Joel,
>
> Thanks for the feedback.  I think the problem-statement draft (now at
> http://tools.ietf.org/html/draft-atlas-irs-problem-statement-00)
> focuses a bit more on the problem and less on the protocol aspects.
>
> The framework does try to describe the need for data models that have
> semantic meaning included - and gives some ideas on what information
> might want to be in some of those data-models.  To get the details
> correct, I think we'll want to drive from agreed upon specific
> vertical use-cases.
>
> I do think that, assuming there is interest, we want to move forward
> to use-cases and nail down a small set of data-models to focus on, at
> least with their requirements.  There could be multiple transfer
> protocols, if we needed them, but it's quite premature to focus on the
> protocol specifics now.
>
> As for the protocol, I tried to focus on the key aspects and/or goals
> that we think the interface needs to have.  I do apologize for the
> extensive use of "streaming" in the doc - I added the key aspects part
> and obviously didn't prune out the streaming adjective everywhere.
> The intent was to to imply the asynchronous, duplex nature - not, say,
> TCP like streaming.
>
> Alia
>
> On Sun, Jul 29, 2012 at 12:44 PM, Joel M. Halpern <[email-masked]> wrote:
>> As far as I can tell, the document could use signifiantly more clarity on
>> the problem to be solved, and the information modeling gaps that appear to
>> exist, and much less (maybe none) discussion of why a new protocol is
>> needed.  It seems to me that the descriptions of existing protocols tend to
>> be based on assumptions that are not borne out by the rest of the document.
>>
>> As an example, the assumption that the solution must be some form of
>> streaming (whatever that means) is not grounded in the document.
>>
>> Yours,
>> Joel M. Halpern
>>
>>
>> On 7/29/2012 12:39 PM, Thomas Nadeau wrote:
>>>
>>>
>>>          We wanted to kick off the discussion here about the framework
>>> draft. What do you think? How can this be improved? Are we on the right
>>> track?
>>>
>>>          The (proposed) Framework can be found here:
>>>
>>> http://lucidvision.com/draft-ward-irs-framework-00.txt
>>>
>>>          We will be sending out a problem statement draft later today as
>>> well.
>>>
>>>          --Tom, Alia, Ward
>>>
>>>
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>

From: Nitin Bahadur <[email-masked]>
To: James Kempf <[email-masked]>, Thomas Nadeau <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 30 Jul 2012 15:33:06 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [irs-discuss] IRS Problem Statement Posted

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 contr=
oller.
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 th=
e
network element's RIB (not the FIB directly).

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

Hope that helps.

Thanks
Nitin

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

I don't understand why streaming is specified in this draft. And I don't un=
derstand why this draft isn't put in the Forces framework. Forces is a fram=
ework explicitedly designed for device to controller communication. Its maj=
or drawback it that it is a framework with a hole in the middle, in that th=
ere 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 int=
o a separate device is, in some cases, an attractive design option. So I th=
ink this should be submitted to the Forces working group, or, at least, rec=
ast 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
>
>
>
> Please review and discuss.
>
> Thanks,
>
> Tom, Alia, Ward
>
>
> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt
>
>
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
>
_______________________________________________
irs-discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/irs-discuss

Date: Mon, 30 Jul 2012 18:27:11 -0400
From: Alia Atlas <[email-masked]>
To: James Kempf <[email-masked]>
Cc: Thomas Nadeau <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS Problem Statement Posted

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

On Mon, Jul 30, 2012 at 6:11 PM, James Kempf <[email-masked]> wro=
te:
> 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 fr=
amework explicitedly designed for device to controller communication. Its m=
ajor 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 stat=
e update. Forces has already established that splitting the control plane i=
nto 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, r=
ecast 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
>>
>>
>>
>> Please review and discuss.
>>
>> Thanks,
>>
>> Tom, Alia, Ward
>>
>>
>> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt
>>
>>
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss

Date: Mon, 30 Jul 2012 18:19:45 -0400
From: Alia Atlas <[email-masked]>
To: "Joel M. Halpern" <[email-masked]>
Cc: [email-masked]
Subject: Re: [irs-discuss] draft-ward-irs-framework

Joel,

Thanks for the feedback.  I think the problem-statement draft (now at
http://tools.ietf.org/html/draft-atlas-irs-problem-statement-00)
focuses a bit more on the problem and less on the protocol aspects.

The framework does try to describe the need for data models that have
semantic meaning included - and gives some ideas on what information
might want to be in some of those data-models.  To get the details
correct, I think we'll want to drive from agreed upon specific
vertical use-cases.

I do think that, assuming there is interest, we want to move forward
to use-cases and nail down a small set of data-models to focus on, at
least with their requirements.  There could be multiple transfer
protocols, if we needed them, but it's quite premature to focus on the
protocol specifics now.

As for the protocol, I tried to focus on the key aspects and/or goals
that we think the interface needs to have.  I do apologize for the
extensive use of "streaming" in the doc - I added the key aspects part
and obviously didn't prune out the streaming adjective everywhere.
The intent was to to imply the asynchronous, duplex nature - not, say,
TCP like streaming.

Alia

On Sun, Jul 29, 2012 at 12:44 PM, Joel M. Halpern <[email-masked]> wrote:
> As far as I can tell, the document could use signifiantly more clarity on
> the problem to be solved, and the information modeling gaps that appear to
> exist, and much less (maybe none) discussion of why a new protocol is
> needed.  It seems to me that the descriptions of existing protocols tend to
> be based on assumptions that are not borne out by the rest of the document.
>
> As an example, the assumption that the solution must be some form of
> streaming (whatever that means) is not grounded in the document.
>
> Yours,
> Joel M. Halpern
>
>
> On 7/29/2012 12:39 PM, Thomas Nadeau wrote:
>>
>>
>>         We wanted to kick off the discussion here about the framework
>> draft. What do you think? How can this be improved? Are we on the right
>> track?
>>
>>         The (proposed) Framework can be found here:
>>
>> http://lucidvision.com/draft-ward-irs-framework-00.txt
>>
>>         We will be sending out a problem statement draft later today as
>> well.
>>
>>         --Tom, Alia, Ward
>>
>>
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss

Date: Mon, 30 Jul 2012 18:14:48 -0400
From: "Joel M. Halpern" <[email-masked]>
To: [email-masked]
Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt

I am finding this document quite confusing.

The primary confusion is that the document first says that it is about 
information that can not be manipulated with existing systems, and then 
proceeds to give a list of use cases all of which can be manipulated 
with existing systems at a suitable degree of abstraction.

As a lesser confusion, the document says that "streaming" is important, 
but then describes "streaming" as "fast, interactive access."  That is 
not streaming.  And depending upon what one means by interactive, plenty 
of systems provide "fest, interactive access."  I realize the document 
later goes on tot talk about speed and frequency of state updates.   But 
that section simply reasserts the earlier terms withotu better 
description or justification.

Yours,
Joel

On 7/30/2012 2:08 PM, [email-masked] wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
> 	Title           : Interface to the Routing System Framework
> 	Author(s)       : Alia Atlas
>                            Thomas Nadeau
>                            Dave Ward
> 	Filename        : draft-ward-irs-framework-00.txt
> 	Pages           : 21
> 	Date            : 2012-07-30
>
> Abstract:
>     This document describes a framework for a standard, programmatic
>     interface for full-duplex, streaming state transfer in and out of the
>     Internet's routing system.  It lists the information that might be
>     exchanged over the interface, and describes the uses of an interface
>     to the Internet routing system.
>

From: James Kempf <[email-masked]>
To: Thomas Nadeau <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 30 Jul 2012 18:11:16 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [irs-discuss] IRS Problem Statement Posted

I don't understand why streaming is specified in this draft. And I don't un=
derstand why this draft isn't put in the Forces framework. Forces is a fram=
ework explicitedly designed for device to controller communication. Its maj=
or drawback it that it is a framework with a hole in the middle, in that th=
ere 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 int=
o a separate device is, in some cases, an attractive design option. So I th=
ink this should be submitted to the Forces working group, or, at least, rec=
ast in the Forces framework.

		jak

> -----Original Message-----
> From: [email-masked]=20
> [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
>=20
>=20
>=20
> Please review and discuss.
>=20
> Thanks,
>=20
> Tom, Alia, Ward
>=20
>=20
> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt
>=20
>=20
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
> =

From: Thomas Nadeau <[email-masked]>
Date: Mon, 30 Jul 2012 15:06:48 -0700
To: "[email-masked]" <[email-masked]>
Subject: [irs-discuss] irs problem statement

FYI...

A new version of I-D, draft-atlas-irs-problem-statement-00.txt
has been successfully submitted by Thomas Nadeau and posted to the
IETF repository.

Filename:	 draft-atlas-irs-problem-statement
Revision:	 00
Title:		 Interface to the Routing System Problem Statement
Creation date:	 2012-07-30
WG ID:		 Individual Submission
Number of pages: 12
URL:             =
http://www.ietf.org/internet-drafts/draft-atlas-irs-problem-statement-00.t=
xt
Status:          =
http://datatracker.ietf.org/doc/draft-atlas-irs-problem-statement
Htmlized:        =
http://tools.ietf.org/html/draft-atlas-irs-problem-statement-00

Abstract:
  As modern networks grow in scale and complexity, the need for rapid
  and dynamic control increases.  With scale, the need to automate even
  the simplest operations is important, but even more critical is the
  ability to quickly interact with more complex operations such as
  policy-based controls.

  In order to enable applications to have access to and control over
  information in the Internet's routing system, we need a publically
  documented interface specification.  The interface needs to support
  real-time, transaction-based interactions using efficient data models
  and encodings.  Furthermore, the interface must support a variety of
  use cases including those where verified control feed-back loops are
  needed.

  This document expands upon these statements of requirements to
  provide a problem statement for an interface to the Internet routing
  system.

The IETF Secretariat

From: Thomas Nadeau <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Mon, 30 Jul 2012 14:18:07 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: [irs-discuss] IRS Problem Statement Posted

Please review and discuss.

Thanks,

Tom, Alia, Ward

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

Date: Sun, 29 Jul 2012 12:44:35 -0400
From: "Joel M. Halpern" <[email-masked]>
To: [email-masked]
Subject: Re: [irs-discuss] draft-ward-irs-framework

As far as I can tell, the document could use signifiantly more clarity 
on the problem to be solved, and the information modeling gaps that 
appear to exist, and much less (maybe none) discussion of why a new 
protocol is needed.  It seems to me that the descriptions of existing 
protocols tend to be based on assumptions that are not borne out by the 
rest of the document.

As an example, the assumption that the solution must be some form of 
streaming (whatever that means) is not grounded in the document.

Yours,
Joel M. Halpern

On 7/29/2012 12:39 PM, Thomas Nadeau wrote:
>
> 	We wanted to kick off the discussion here about the framework draft. What do you think? How can this be improved? Are we on the right track?
>
> 	The (proposed) Framework can be found here:
>
> http://lucidvision.com/draft-ward-irs-framework-00.txt
>
> 	We will be sending out a problem statement draft later today as well.
>
> 	--Tom, Alia, Ward
>
> 	
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
>

From: Thomas Nadeau <[email-masked]>
Date: Sun, 29 Jul 2012 09:39:57 -0700
To: [email-masked]
Subject: [irs-discuss] draft-ward-irs-framework

	We wanted to kick off the discussion here about the framework =
draft. What do you think? How can this be improved? Are we on the right =
track?

	The (proposed) Framework can be found here:

http://lucidvision.com/draft-ward-irs-framework-00.txt

	We will be sending out a problem statement draft later today as =
well.

	--Tom, Alia, Ward

=09=

From: Alia Atlas <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Thu, 26 Jul 2012 22:25:18 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: [irs-discuss] IRS framework draft

I'm excited to see so much interested in IRS and hope we can get started on=
 some good discussion.  For those who didn't see Tom's email to related mai=
ling lists, the relevant draft to read is at:

http://www.lucidvision.com/draft-ward-irs-framework-00.txt

We will be discussing IRS during the Routing Area Open Meeting on Thurs mor=
ning.

Regards,
Alia

From: IETF Secretariat <[email-masked]>
To: IETF Announcement List <[email-masked]>
Date: Thu, 26 Jul 2012 17:45:29 -0700
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [irs-discuss] New Non-WG Mailing List: irs-discuss -- Interface to The Internet	Routing System (IRS)

A new IETF non-working group email list has been created.

List address: [email-masked]
Archive: http://www.ietf.org/mail-archive/web/irs-discuss/
To subscribe: https://www.ietf.org/mailman/listinfo/irs-discuss

Purpose: This list is for the discussion of an interface to the routing =

system (IRS) that allows applications to rapidly and dynamically install =

routing state into routers, and to learn sufficient information from =

routers to make timely, data-based decisions about what routing state to =

specify. Such an interface would facilitate control and diagnosis of the =

routing infrastructure, as well as enabling sophisticated applications =

to be built on top of today's routed networks. The IRS is conceived as a =

programmatic, streaming interface for transferring state into and out of =

the Internet's routing system, recognizing that the routing system and a =

router's OS provide useful mechanisms that applications could harness to =

accomplish application-level goals. A fundamental component of the IRS =

is a clear data model that defines the semantics of the information that =

can be written and read. =

For additional information, please contact the list administrators.