Re: [irs-discuss] IRS comments

"Dutta, Pranjal K (Pranjal)" <pranjal.dutta@alcatel-lucent.com> Thu, 30 August 2012 20:41 UTC

Return-Path: <pranjal.dutta@alcatel-lucent.com>
X-Original-To: irs-discuss@ietfa.amsl.com
Delivered-To: irs-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB2421F85AA for <irs-discuss@ietfa.amsl.com>; Thu, 30 Aug 2012 13:41:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.4
X-Spam-Level:
X-Spam-Status: No, score=-7.4 tagged_above=-999 required=5 tests=[AWL=-0.802, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23w8StzmtaRW for <irs-discuss@ietfa.amsl.com>; Thu, 30 Aug 2012 13:41:13 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0054421F85A7 for <irs-discuss@ietf.org>; Thu, 30 Aug 2012 13:41:12 -0700 (PDT)
Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q7UKf5oH014515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 Aug 2012 15:41:07 -0500 (CDT)
Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q7UKf1i4020582 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 31 Aug 2012 02:11:02 +0530
Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Fri, 31 Aug 2012 02:11:01 +0530
From: "Dutta, Pranjal K (Pranjal)" <pranjal.dutta@alcatel-lucent.com>
To: Edward Crabbe <edc@google.com>, Alia Atlas <akatlas@gmail.com>
Date: Fri, 31 Aug 2012 02:10:59 +0530
Thread-Topic: [irs-discuss] IRS comments
Thread-Index: Ac2G4ZvqJ0Jo5IAaSs2Ri0esYrpMZwADbBRg
Message-ID: <C584046466ED224CA92C1BC3313B963E13F0B8C87F@INBANSXCHMBSA3.in.alcatel-lucent.com>
References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <CAG=JvvjYk_E6+Qdidyyjc5oDss9HeA2aq2pt5ciQeX06fuiWsQ@mail.gmail.com> <CAG4d1reLL2_4KRb6yseJK9WTB47YzumMBGdu+UwcOWXxmE0M8Q@mail.gmail.com> <CAG=JvvjVhGsVcSzEFxDKKfNckQxgQiWeezWvwpcoAOSgOP--Nw@mail.gmail.com> <CAG4d1rd_p6x_+PsHWtsYU=oOCT-GnmnZNL+MHcJf4NEG5boP7A@mail.gmail.com> <B37E6A2CE5957F4E83C1D9845A0FFE38014A33BC4A@MDWEXGMB02.ciena.com> <CAG4d1reWGjUU-z=9Gx_MvetAWF6wM8oUMpQRc9hxOg1MU37X_w@mail.gmail.com> <A3C4E51A53661B4EBEE7C5F5E6FCDEB5025AB94FE6D2@USEXCHANGE.corp.extremenetworks.com> <CAG4d1rfD8_0WgzRqH-OVAxfn1RYNfY_ynwkcmqN3MBYyrn5TnQ@mail.gmail.com> <3512BB31280C39448A9880F61DD54CEB09C07E@xmb-aln-x09.cisco.com> <CAG4d1rcvk1RmRmrpCwiAGx9s0v3X9aPECdeF1Wz7WSuYwzdFKA@mail.gmail.com> <CACKN6JH8eiYty3QOZ+E5Nt0wO3nYn87yB3pKixJK-3dnaOXfLQ@mail.gmail.com> <CACKN6JFMZqOnHU=vEkx8WxwSLjg5MYY=-VoJ7uOt8SAzvbAT6Q@mail.gmail.com> <A3C4E51A53661B4EBEE7C5F5E6FCDEB5025AB94FE847@USEXCHANGE.corp.extremenetworks.com> <B37E6A2CE5957F4E83C1D9845A0FFE38014A33C0A0@MDWEXGMB02.ciena.com> <CAG4d1rehfWk-HX27eysze8zdDzjNk4h4wwj2zV6_WJWxoNxY8Q@mail.gmail.com> <B37E6A2CE5957F4E83C1D9845A0FFE38014A33C26F@MDWEXGMB02.ciena.com> <B17A6910EEDD1F45980687268941550FB7B7B6@MISOUT7MSGUSR9I.ITServices.sbc.com> <B37E6A2CE5957F4E83C1D9845A0FFE38014A33C2BD@MDWEXGMB02.ciena.com> <C584046466ED224CA92C1BC3313B963E09F22C5413@INBANSXCHMBSA3.in.alcatel-lucent.com> <B37E6A2CE5957F4E83C1D9845A0FFE38014A33C554@MDWEXGMB02.ciena.com> <C584046466ED224CA92C1BC3313B963E09F22C55F2@INBANSXCHMBSA3.in.alcatel-lucent.com> <CAG4d1rfEkxAu_XbeVN_76mw+=-Rm45-eveuKMWbeXBTuktrj_w@mail.gmail.com> <CACKN6JFNHSM=Tu=tPCUe7zWm1g9LRfa6Bv9kvr+uoriVhmLhBQ@mail.gmail.com>
In-Reply-To: <CACKN6JFNHSM=Tu=tPCUe7zWm1g9LRfa6Bv9kvr+uoriVhmLhBQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_C584046466ED224CA92C1BC3313B963E13F0B8C87FINBANSXCHMBSA_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
Cc: "UTTARO, JAMES" <ju1738@att.com>, "Shah, Himanshu" <hshah@ciena.com>, "irs-discuss@ietf.org" <irs-discuss@ietf.org>
Subject: Re: [irs-discuss] IRS comments
X-BeenThere: irs-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <irs-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/irs-discuss>, <mailto:irs-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/irs-discuss>
List-Post: <mailto:irs-discuss@ietf.org>
List-Help: <mailto:irs-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/irs-discuss>, <mailto:irs-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Aug 2012 20:41:15 -0000

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:edc@google.com]
Sent: Thursday, August 30, 2012 11:59 AM
To: Alia Atlas
Cc: Dutta, Pranjal K (Pranjal); UTTARO, JAMES; Shah, Himanshu; irs-discuss@ietf.org
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 <akatlas@gmail.com<mailto:akatlas@gmail.com>> 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)
<pranjal.dutta@alcatel-lucent.com<mailto:pranjal.dutta@alcatel-lucent.com>> 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
irs-discuss@ietf.org<mailto:irs-discuss@ietf.org>
https://www.ietf.org/mailman/listinfo/irs-discuss