Re: [irs-discuss] IRS comments

[Alia Atlas <[e-mail]>]

On the encap/decap, I certainly view encap as simply a different type
of next-hop that a route to the RIB can have.  Similarly, one can view
decap as treating a particular label/prefix - though that may require
more complexity.

Negotiation is another area to think about too.  Clearly, there will
be some capability negotiation needed as part of IRS - as well as the
ability to query for what capabilities are supported by the routing
element.

Incidentally, if you are interested in writing down your thoughts
around different architectures for where parts of the routing system
might live and how they should/would interact with IRS, I'd encourage
you to do so and to chat with Dave Meyer, who has agreed to take on
looking at such pieces.

While I do think that migrating the entire routing system except for
RIB off of a routing element would be for rather specialized
environments, I am also concerned that we consider the different
architectural possibilities when defining IRS so that we don't end up
going down an insufficient path.

Alia

On Thu, Aug 30, 2012 at 9:16 PM, Edward Crabbe <[e-mail]> wrote:
> Yep;  not having to run an IGP on the box, which is great for those people
> not wanting / needing core internet protocols on their devices.  The
> standard set of 'SDN' talking appoints applies here in terms of development
> speed, performance improvements resulting from use of modern commodity
> compute, friendliness of development environment, potential for decreased
> bug count* etc etc.
>
> It's a specialized use case, but it exists.
>
> However, my fundamental point is that with IRS as defined currently (ie PBR
> with extensible match fields on on RIB recursion + additional monitoring and
> data collection hooks) you can do hypothetically do away with IGPs.  Indeed,
> assuming that the encaps is applied at some other device (since IRS as
> currently described doesn't account for encap/decap application or
> negotiation functionality)  you can effectively replace a significant number
> of protocols (including stateful PCE) should you want to.   :P
>
> <can of worms>
>
> *The benefits in terms of decreased bug counts above is really varies with
> how complex we make IRS of course.
>
> On Thu, Aug 30, 2012 at 6:01 PM, Dutta, Pranjal K (Pranjal)
> <[e-mail]> wrote:
>>
>> Yep, the context of our original discussion was never PCE as we understand
>> its CSPF or some form like that. Our concern was – is there a strong use
>>
>> case for non-constrained SPF?
>>
>>
>>
>> ________________________________
>>
>> From: Edward Crabbe [mailto:[e-mail]]
>> Sent: Thursday, August 30, 2012 5:34 PM
>>
>>
>> To: Dutta, Pranjal K (Pranjal)
>> Cc: Alia Atlas; UTTARO, JAMES; Shah, Himanshu; [e-mail]
>> Subject: Re: [irs-discuss] IRS comments
>>
>>
>>
>> Nope, not specifically, but it strongly implies that there is some form of
>> SPF running given the use of constraints in the draft.
>>
>> On Thu, Aug 30, 2012 at 4:16 PM, Dutta, Pranjal K (Pranjal)
>> <[e-mail]> wrote:
>>
>> That doesn’t talk about centralized SPF, does it ?
>>
>>
>>
>> ________________________________
>>
>> From: Edward Crabbe [mailto:[e-mail]]
>> Sent: Thursday, August 30, 2012 4:12 PM
>>
>>
>> To: Dutta, Pranjal K (Pranjal)
>> Cc: Alia Atlas; UTTARO, JAMES; Shah, Himanshu; [e-mail]
>> Subject: Re: [irs-discuss] IRS comments
>>
>>
>>
>> http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-01
>>
>> On Thu, Aug 30, 2012 at 4:09 PM, Dutta, Pranjal K (Pranjal)
>> <[e-mail]> wrote:
>>
>> ‘operational model’ = IETF draft that describes the use case.
>>
>> ‘large’ = 40K LSAs, 500 IGP nodes.
>>
>>
>>
>> ________________________________
>>
>> From: Edward Crabbe [mailto:[e-mail]]
>> Sent: Thursday, August 30, 2012 2:44 PM
>>
>>
>> To: Dutta, Pranjal K (Pranjal)
>>
>> Cc: Alia Atlas; UTTARO, JAMES; Shah, Himanshu; [e-mail]
>>
>>
>> Subject: Re: [irs-discuss] IRS comments
>>
>>
>>
>> please define 'operational model' ( and 'large' :) .
>>
>> On Thu, Aug 30, 2012 at 1:40 PM, Dutta, Pranjal K (Pranjal)
>> <[e-mail]> wrote:
>>
>> Hi,
>>
>>          I believe that’s 10% of what overall work that router does today
>> w.r.t routing. I would like to see an operational model how such centralized
>> SPF can
>>
>> provide end-to-end convergence of large number of flows efficiently.
>>
>>
>>
>> Thanks,
>>
>> Pranjal
>>
>>
>>
>> ________________________________
>>
>> From: Edward Crabbe [mailto:[e-mail]]
>> Sent: Thursday, August 30, 2012 11:59 AM
>> To: Alia Atlas
>> Cc: Dutta, Pranjal K (Pranjal); UTTARO, JAMES; Shah, Himanshu;
>> [e-mail]
>>
>>
>> Subject: Re: [irs-discuss] IRS comments
>>
>>
>>
>> Alia;
>>
>>
>>
>> If there is
>>
>>
>>
>> a) a mechanism for installing routes, pbr or otherwise, which recurse to
>> directly connected nexthops
>>
>> b) a mechanism for gathering topological information
>>
>>
>>
>> then you've inherently enabled centralized spf.
>>
>>
>>
>> On Thu, Aug 16, 2012 at 9:34 AM, Alia Atlas <[e-mail]> wrote:
>>
>> I haven't seen a good description of what is intended or desired by
>> moving the SPF functionality to a centralized location.  Clearly such
>> centralization can have a very bad impact on convergence - which is a
>> strong motivator for simultaneously computing fast-reroute
>> alternatives (with guaranteed coverage ala MRT) and installing both.
>>
>> I don't see IRS as having a way of "turning off" the SPF computation
>> in the IGP; a different lobotomized IGP protocol/process would be
>> needed.
>>
>> Alia
>>
>>
>> On Thu, Aug 16, 2012 at 12:14 PM, Dutta, Pranjal K (Pranjal)
>> <[e-mail]> wrote:
>> > "LSDB (I saw an email which talks about reducing IGP to link
>> >> distribution protocol and running SPF in centralized network
>> >> controller)"
>> >
>> > I have seen discussions in the past on this and in fact I didn't get
>> > precisely what is meant. If anybody in the list could brief very
>> > precisely that would help a lot.
>> >
>> > Here is my understanding - the routers would do LSA/LSP flooding for
>> > OSPF/ISIS as it is done today. So routers would build neighboring
>> > relationship/adjacencies to participate in flooding and each router builds
>> > its LSDB.
>> >
>> > Then the IRS "application" would track LSDB changes and pull up the
>> > "diffs" from each router (thru "controller") whenever there is a change. The
>> > application would compute SPF on behalf of each router (LSDB). The result of
>> > the compute would be pushed by application to each Router (thru controller)
>> > and inject entries into RIB.
>> >
>> > Is that correct? How different this going to be from PCE?
>> >
>> > If this is correct then perhaps we would like to ask what are the
>> > scalability numbers in LSDB we are talking about?
>> >
>> > The "application" would be running in a high performance server and so
>> > SPF compute there is not an issue and perhaps it is good way to synchronize
>> > FIB update (to a certain extent) to avoid u-loops etc.
>> >
>> > But when we are managing all routers in the purview of the application,
>> > the computing power in each router is not uniform. To be realistic, I have
>> > some concerns on how much "real-timeness" we could achieve between
>> > application and controllers on such proposals, esp. when scaling numbers are
>> > high. This leads to higher time lag on inconsistency between application SPF
>> > compute and FIB update. It's almost like the classic "slow peering" issues
>> > with TCP like protocols - the high performance peer is slowed down by low
>> > performance peer.
>> >
>> > Static route interface is good thing because it is a state that persists
>> > longer.
>> >
>> > IGPs may be deployed in very dynamic environments where tight coupling
>> > is desirable between SPF compute and FIB update. In scaled environments the
>> > issue is less about SPF compute time and is more about synchronizing the
>> > FIB.
>> >
>> > Running on-demand CSPF by IRS application may be fine because of
>> > persistency of RSVP-TE tunnels in dynamic environments.
>> >
>> > I apologize if I misunderstood the intent.
>> >
>> > Thanks,
>> > Pranjal
>>
>> ---snip---
>>
>> _______________________________________________
>> irs-discuss mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>
>>
>>
>>
>>
>>
>>
>>
>
>