Re: [irs-discuss] IRS comments

Edward Crabbe <edc@google.com> Fri, 31 August 2012 00:34 UTC

Return-Path: <edc@google.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 0C3BB21F84EC for <irs-discuss@ietfa.amsl.com>; Thu, 30 Aug 2012 17:34:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.309
X-Spam-Level:
X-Spam-Status: No, score=-102.309 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
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 F5AQ9kc8GZUs for <irs-discuss@ietfa.amsl.com>; Thu, 30 Aug 2012 17:34:29 -0700 (PDT)
Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id D9D7D21F84EA for <irs-discuss@ietf.org>; Thu, 30 Aug 2012 17:34:28 -0700 (PDT)
Received: by ieak13 with SMTP id k13so1436925iea.31 for <irs-discuss@ietf.org>; Thu, 30 Aug 2012 17:34:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=htXmvrS2BBvz0tthUwo9TfC0aPgF4RJ+pTrNUPU4VtU=; b=WukxZv7aBNhYvBKbx+aij8lJzJmUbRUGyXpUKrLV5lx3R26jgfkol1NTSS5gT5e2pV RhoxdGm1A6ys/zKh/4lNOIfbW0vgsGixdzB57OZBlRyOmpOMvCsBRCj6HUFPcVmjibRp +oYBZruSWgiepwcluNbz3v62YoGuKc6YnNw91oQ14XEwXc9+6n/bFgMoCVinNHUmDvX4 XUT5gn1RX3w1tFil6g0WiKdmgU5FWTE2Kli0x9cPmRQQlpwVNigS5eaa5Shdv8Kb2W0S IV89OnJde6SoCyw1n6k6S5e0WmFhzQG/liCWvaPlYkfAwo6IodROPG7h12y5l1oqZkxq ED8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=htXmvrS2BBvz0tthUwo9TfC0aPgF4RJ+pTrNUPU4VtU=; b=JC8NQe9FxS+4ML2QGuAb5+bjEY+DdZEelv+W8v0KdAtaPUUViX6iiEdjnLmQdzpQK3 jzPBg/gEn3iryvc38PRRPn6xyTJKiJslLHPT6956fNUsNlJ2aYMu9VGJmxE9ZWx7R0DE xjIzhi+X8McR91SK44LHBRaz9PdsWAxpsdKMAinmka/J9hR9hgQFpTVsV9SW/OlAehw1 1kg3cEG9eCOm4XE59CXCVOcQpH1sh24sannOAyHMoKhereMZYFILtsq191oqkv9TYucz mt2UArjSwew+JNS/yHp4+O9ae5iJMBLy8exzbyvJk1PDSAZGCeTyrWG+H1x35GXUEFg1 XXhQ==
Received: by 10.50.214.1 with SMTP id nw1mr303714igc.2.1346373268319; Thu, 30 Aug 2012 17:34:28 -0700 (PDT)
Received: by 10.50.214.1 with SMTP id nw1mr303697igc.2.1346373268043; Thu, 30 Aug 2012 17:34:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.50.237.67 with HTTP; Thu, 30 Aug 2012 17:33:46 -0700 (PDT)
In-Reply-To: <C584046466ED224CA92C1BC3313B963E13F0B8C89F@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> <C584046466ED224CA92C1BC3313B963E13F0B8C87F@INBANSXCHMBSA3.in.alcatel-lucent.com> <CACKN6JG9MkNgVi0F4t7YFjsAFFfasGPsTkTJ5BDYV8ZZtq_-dw@mail.gmail.com> <C584046466ED224CA92C1BC3313B963E13F0B8C89B@INBANSXCHMBSA3.in.alcatel-lucent.com> <CACKN6JELp0rNN60z4b0Xf1xhRnVhSqHcU64wrD=O5SCmWvWreQ@mail.gmail.com> <C584046466ED224CA92C1BC3313B963E13F0B8C89F@INBANSXCHMBSA3.in.alcatel-lucent.com>
From: Edward Crabbe <edc@google.com>
Date: Thu, 30 Aug 2012 17:33:46 -0700
Message-ID: <CACKN6JF_tfjKY7aYEceES9D-LjYBh8KB0OUsjCuy-0jGTMvUhQ@mail.gmail.com>
To: "Dutta, Pranjal K (Pranjal)" <pranjal.dutta@alcatel-lucent.com>
Content-Type: multipart/alternative; boundary=14dae9340d076077ec04c884f457
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQmFTWOth7prKf4yULvuQKuYgNd5E817sNM7Prb79Iv6Ca7Xjq8/MSaSdSbamKffznlSGtTpLVxGqR6XA4rfbw7Ujq4AfTKFlWWQqMkLaK51W0Cf4HpcAeSNLM7HCqkBdxa/5ElfX6cLBFWubXWDaI3e7VddSebudJBhdh6HkE4tTt5+ioLp2b70er646klu3g4UyDFj
Cc: "irs-discuss@ietf.org" <irs-discuss@ietf.org>, "UTTARO, JAMES" <ju1738@att.com>, "Shah, Himanshu" <hshah@ciena.com>, Alia Atlas <akatlas@gmail.com>
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: Fri, 31 Aug 2012 00:34:30 -0000

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) <
pranjal.dutta@alcatel-lucent.com> wrote:

> **
>
> That doesn’t talk about centralized SPF, does it ?****
>
> ** **
>  ------------------------------
>
> *From:* Edward Crabbe [mailto:edc@google.com]
> *Sent:* Thursday, August 30, 2012 4:12 PM
>
> *To:* **Dutta, Pranjal K** (Pranjal)
> *Cc:* Alia Atlas; UTTARO, JAMES; **Shah, Himanshu**; **
> irs-discuss@ietf.org**
> *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) <
> pranjal.dutta@alcatel-lucent.com> wrote:****
>
> ‘operational model’ = IETF draft that describes the use case.****
>
> ‘large’ = 40K LSAs, 500 IGP nodes.****
>
>  ****
>  ------------------------------
>
> *From:* Edward Crabbe [mailto:edc@google.com]
> *Sent:* Thursday, August 30, 2012 2:44 PM****
>
>
> *To:* **Dutta, Pranjal K** (Pranjal)****
>
> *Cc:* Alia Atlas; UTTARO, JAMES; **Shah, Himanshu**; irs-discuss@ietf.org*
> ***
>
>
> *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) <
> pranjal.dutta@alcatel-lucent.com> 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: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> 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> 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
> https://www.ietf.org/mailman/listinfo/irs-discuss****
>
>  ****
>
>  ****
>
> ** **
>