Re: [irs-discuss] IRS comments

[Alia Atlas <[e-mail]>]

Definitely agree - an IRS client has specific authorization and scope
for what it can do - and that includes what prioritization it can
specify for its static routes and so on..

Alia

On Wed, Aug 15, 2012 at 7:50 PM, UTTARO, JAMES <[e-mail]> wrote:
> Inject routes yes, but I would not assume that implies that all state from IRS is prioritized.. I think an important point to remember is that how IRS interfaces with routing state learned via network protocols needs to be part of this effort..
>
> Jim Uttaro
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Shah, Himanshu
> Sent: Wednesday, August 15, 2012 6:57 PM
> To: Alia Atlas
> Cc: [e-mail]
> Subject: Re: [irs-discuss] IRS comments
>
> OK - So that I am clear...
>
> IRS would provide interface to RIB such that routes can be injected with priority
> and the local routing table manager on the node would then apply precedence rules, select the route,
> do ARP resolve (if ETH) and inject the prefix with next-hop info into the FIB.
>
> The next step is then programming the FIB on the line card (if applicable).
>
> Would make sense for IRS to not provide interface to the FIB on the second step.
> But you are saying that it would also not provide interface to FIB of the first step.
>
> Is that correct?
>
> /himanshu
>
> -----Original Message-----
> From: Alia Atlas [mailto:[e-mail]]
> Sent: Wednesday, August 15, 2012 6:05 PM
> To: Shah, Himanshu
> Cc: [e-mail]
> Subject: Re: [irs-discuss] IRS comments
>
> I don't see IRS going below the RIB layer to FIB.
>
> Alia
>
> On Wed, Aug 15, 2012 at 2:21 PM, Shah, Himanshu <[e-mail]> wrote:
>> I will let Ed clarify on what he means by "controller" .
>>
>>
>>
>> But here is my view of "application", "controller", "use-case" etc
>> etc,
>>
>>
>>
>> When an XaaS processes a request it takes into consideration of
>> availability of the CPU, memory, application data, cost of power, etc.
>> to instantiate a VM on some host machine.
>>
>> One additional resource taken into consideration is the availability
>> and/or requirement of the network connectivity between the resources
>>
>> such as VM, application data, requester, etc.
>>
>>
>>
>> The provider of XaaS thingy is the application server.
>>
>> (Centralized) Network "Controller(s)"  knows current state of network
>> infrastructure and (to be decided how much it) controls member network
>> nodes using IRS.
>>
>> The "use case" here is to be able to dynamically create L2/L2.5/L3
>> connectivity with specific TE characteristics between the (perhaps
>> geographically dispersed) resource points.
>>
>>
>>
>> In hierarchical fashion:   Application server <- (application interface) ->
>> Network Controller <- (IRS) -> Network Node
>>
>>
>>
>> As we heard at IETF, IRS has tentacles in network nodes from BGP
>> policies, all the way down to FIBs/LFIBs/ACL.
>>
>>
>>
>> So we need use cases for which applications would require
>> accessibility to -
>>
>> BGP Policies
>>
>> RIB
>>
>> LSDB ( I saw an email which talks about reducing IGP to link
>> distribution protocol and running SPF in centralized network
>> controller)
>>
>> LIB
>>
>> FIB
>>
>> ACL (this is perhaps obvious)
>>
>> Etc etc
>>
>>
>>
>> I broad brushed and simplified a lot here to express my view - not
>> sure if this jives with others.
>>
>>
>>
>> /Himanshu
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> From: [e-mail]
>> [mailto:[e-mail]] On Behalf Of Olen Stokes
>> Sent: Wednesday, August 15, 2012 1:30 PM
>> To: Edward Crabbe; Alia Atlas
>> Cc: David Lake (dlake); [e-mail]
>>
>>
>> Subject: Re: [irs-discuss] IRS comments
>>
>>
>>
>> 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
>>
>>
>>
>>
> _______________________________________________
> irs-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/irs-discuss