Re: [irs-discuss] IRS comments

[Alia Atlas <[e-mail]>]

I don't think it implies a reference to an OpenFlow Controller.  An
IRS client might live in a controller application that serves a
similar functional role.  This is part of what use-cases may help
with.

Alia

On Wed, Aug 15, 2012 at 2:38 PM, Olen Stokes
<[e-mail]> wrote:
> I understand that.  Sorry, I should have been more specific.  I am trying to
> understand if usage of the word “controller” on this list implies a
> reference to any existing description such as “Open Flow Controller”.
>
>
>
> Olen
>
>
>
> From: Edward Crabbe [mailto:[e-mail]]
> Sent: Wednesday, August 15, 2012 2:20 PM
> To: Olen Stokes
> Cc: Alia Atlas; David Lake (dlake); [e-mail]
>
>
> Subject: Re: [irs-discuss] IRS comments
>
>
>
> The software (interacting with the 'applications' and) generating the actual
> PDUs understood by the NEs.
>
>
>
> On Wed, Aug 15, 2012 at 10:30 AM, Olen Stokes <[e-mail]>
> wrote:
>
> Thanks.  Can you also give us what you mean by “controller”.
>
>
>
> Olen
>
>
>
> From: Edward Crabbe [mailto:[e-mail]]
> Sent: Wednesday, August 15, 2012 1:24 PM
> To: Alia Atlas
> Cc: David Lake (dlake); Olen Stokes; [e-mail]
>
>
> Subject: Re: [irs-discuss] IRS comments
>
>
>
> s/wg/pre-BOF proto-wg :P/g
>
> On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe <[e-mail]> wrote:
>
> +1 Alia.  There's been a lot of confusion over this term.  Having gone a few
> rounds with folks on this one in other forums, I'll point out that what most
> people mean by application (myself included) is some set of control software
> (a scheduler, a path optimizer etc)  that provides instructions to the
> controller, which are in turn translated to the appropriate PDUs.
>
>
>
> Having 'end user' applications request/make changes to forwarding state
> without an intermediate broker/aggregator acting on their behalf sounds like
> a recipe for disaster for operational networks, or, as is more likely, a
> quick hike to the protocol grave yard (followed by a long grave-side party
> :P) for the wg.
>
>
>
> my 2c.
>
>
>
> On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas <[e-mail]> wrote:
>
> Hi David,
>
> We do need to clarify what is meant by an application.  I would not
> expect that real user-land applications would talk directly to routing
> devices via IRS.  I can see that going through an intermediary.  The
> IRS abstractions are unlikely to be as high-level as user-land
> applications would want and the security and policy issues would get
> exciting.
>
> Clarifying what applications are more in-scope initially is part of
> where use-cases will help.  Can you write up ones to
> categorize/describe your thoughts?
>
> Alia
>
>
> On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) <[e-mail]>
> wrote:
>> As another newbie to this, I have some questions about "application
>> vendors."
>>
>> Who is the target audience here ?   That will determine what functionality
>> and abstraction of the network we need to expose to that "application."
>>
>> This presently appears to be a little confused - at least in my mind.  The
>> draft talks very much as if the application we are addressing is an OSS/BSS
>> system, essentially provisioning from the domain owner.
>>
>> However, linking this to the wider goals of SDN as voiced by
>> customers/users at the first Open Network Summit, there appears to be a
>> desire for cross-domain and user-land application integration.
>>
>> At this level - as an example giving a content cache the ability to ensure
>> delivery of an HD video to an end user - the application will not be
>> interested in the underlying topology of the network; it will  need to know
>> that application X can be delivered with parameters Y between reading from
>> the content store to delivery to the user's browser.   How the stream
>> traverses the infrastructure is immaterial.
>>
>> Are we intending that IRS satisfies BOTH these requirements (i.e. for ALL
>> applications ?), or should we be more prescriptive about which application
>> space we are addressing ?
>>
>> Thanks
>>
>> David
>>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]]
>> On Behalf Of Alia Atlas
>> Sent: Wednesday, August 15, 2012 7:23 AM
>> To: Olen Stokes
>> Cc: [e-mail]
>> Subject: Re: [irs-discuss] IRS comments
>>
>> I have not specifically heard from application vendors about this.
>> My current plan is that we focus on a Use-Cases draft and define within
>> that some motivating use-cases that we agree are good first targets.  Those
>> can drive which subset of functionality we focus on.
>>
>> More use-cases are, of course, quite welcome.  Posting them to the mailing
>> list is a good first start.  Russ White is starting the general use-cases
>> draft based on the three use-cases that he sent to the list.
>>
>> Alia
>>
>> On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes <[e-mail]>
>> wrote:
>>> Are there applications vendors out there that already have specific
>>> requirements for what this " subset of the data-models for sub-interfaces"
>>> should be?
>>>
>>> Olen
>>>
>>> -----Original Message-----
>>> From: [e-mail]
>>> [mailto:[e-mail]] On Behalf Of Alia Atlas
>>> Sent: Wednesday, August 15, 2012 9:08 AM
>>> To: Shah, Himanshu
>>> Cc: Gert Grammel; [e-mail]; Lenny Giuliano; Thomas Nadeau;
>>> Alia Atlas; Scott Whyte
>>> Subject: Re: [irs-discuss] IRS comments
>>>
>>> Hi Himanshu,
>>>
>>> Welcome.   I agree that IRS isn't going to spring into being fully
>>> formed - I expect that we'll focus on a subset of the data-models for
>>> sub-interfaces along with an associated protocol (whether that is a new one
>>> or extending an existing one).
>>>
>>> Alia
>>>
>>> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu <[e-mail]> wrote:
>>>> Newbie to this discussions list and have read only a last couple of
>>>> mails, so pardon the repeat if somebody has already raised the following as
>>>> a concern.
>>>>
>>>> I realize we are early in IRS architecture definition but one thing to
>>>> keep in mind is the user experience.
>>>> We need to make sure that exposed interface to
>>>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc  provide a consistent predictive
>>>> action/response/events even when different implementations has varying
>>>> capabilities.
>>>>
>>>> At the moment it seems like a wild wild west.
>>>> Perhaps IRS can be defined in phases starting with a simpler, limited
>>>> version..
>>>>
>>>> Thanks,
>>>> himanshu
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: [e-mail]
>>>> [mailto:[e-mail]] On Behalf Of Alia Atlas
>>>> Sent: Monday, August 13, 2012 8:41 AM
>>>> To: Scott Whyte
>>>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano;
>>>> [e-mail]
>>>> Subject: Re: [irs-discuss] IRS comments
>>>>
>>>> ...snip...
>>>>
>>>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte <[e-mail]> wrote:
>>>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas <[e-mail]> wrote:
>>>>
>>>>>> I do think it is important to have the RIB as an arbitration mechanism
>>>>>> on the device.   Russ's suggestion that for the RIB sub-interface, the
>>>>>> IRS agent might communicate logically to an IRS routing process
>>>>>> gives good semantics and interactions.  Obviously, implementations
>>>>>> may differ.
>>>>>
>>>>> As long as the arbitration mechanism is reconfigurable by the
>>>>> operator to whatever precedence they want, I agree.  Its not clear
>>>>> to me if various RIB implementations treat all proffered routes the
>>>>> same, nor if they store the same meta-data with all protocol sources.
>>>>> So there needs to be some way for the operator to leverage exposed
>>>>> protocol-specific optimizations, without conflict from the other
>>>>> routing processes, if they so desire.  OTOH if it can all be done
>>>>> via static routes, it seems much simpler. :)
>>>>
>>>> Clearly the IRS sub-interface for the RIB needs to introduce/define the
>>>> different precedences; my assumption is that it would be per route with a
>>>> well-defined small set of meta-data.  This is part of where having good
>>>> use-cases will help us understand what behavior is necessary.  The static
>>>> routes do seem like a simpler case to start with.
>>>>
>>>> Alia
>>>> _______________________________________________
>>>> irs-discuss mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>> _______________________________________________
>> irs-discuss mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/irs-discuss
>
>
>
>
>
>