Re: [irs-discuss] IRS comments

[Edward Crabbe <[e-mail]>]

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