Re: [irs-discuss] IRS comments

[Edward Crabbe <[e-mail]>]

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