Re: [irs-discuss] IRS comments

"Dutta, Pranjal K (Pranjal)" <pranjal.dutta@alcatel-lucent.com> Thu, 16 August 2012 23: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 9B6BF21F8499 for <irs-discuss@ietfa.amsl.com>; Thu, 16 Aug 2012 16:41:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.336
X-Spam-Level:
X-Spam-Status: No, score=-9.336 tagged_above=-999 required=5 tests=[AWL=1.263, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 kP7DCPZEBDCf for <irs-discuss@ietfa.amsl.com>; Thu, 16 Aug 2012 16:41:34 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 84C0721F849D for <irs-discuss@ietf.org>; Thu, 16 Aug 2012 16:41:34 -0700 (PDT)
Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q7GNfKqI008940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Aug 2012 18:41:25 -0500 (CDT)
Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q7GNfHHi000505 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 17 Aug 2012 05:11:19 +0530
Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Fri, 17 Aug 2012 05:11:17 +0530
From: "Dutta, Pranjal K (Pranjal)" <pranjal.dutta@alcatel-lucent.com>
To: Ramon Casellas <ramon.casellas@cttc.es>
Date: Fri, 17 Aug 2012 05:11:14 +0530
Thread-Topic: [irs-discuss] IRS comments
Thread-Index: Ac170FD8YsogUq94QjGrnd+7/mQr+QALs+4g
Message-ID: <C584046466ED224CA92C1BC3313B963E09F22C5669@INBANSXCHMBSA3.in.alcatel-lucent.com>
References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> <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> <502D2692.2030105@cttc.es>
In-Reply-To: <502D2692.2030105@cttc.es>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
Cc: "irs-discuss@ietf.org" <irs-discuss@ietf.org>, 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: Thu, 16 Aug 2012 23:41:35 -0000

Thanks for detailed explanation. My question on LSA flooding was not in the context of PCE or CSPF/TE-DB but on the issue of "regular/unconstrained" SPF computation in IGPs. The dynamics between a) CSPF on TE-DB and b) regular SPF on each link state change in a network are much different. My concern was primarily on b) - I don't see what it achieves and in fact may degrade FIB convergence performance abysmally. 

As Alia has clarified, we haven't heard of any clear, realistic use case of b). I agree with you that missing pieces in PCE may be addressed thru IRS. 

Thanks,
Pranjal



-----Original Message-----
From: Ramon Casellas [mailto:ramon.casellas@cttc.es] 
Sent: Thursday, August 16, 2012 9:58 AM
To: Dutta, Pranjal K (Pranjal)
Cc: Alia Atlas; irs-discuss@ietf.org
Subject: Re: [irs-discuss] IRS comments

On 08/16/2012 06:14 PM, Dutta, Pranjal K (Pranjal) 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?
>


Pranjal, all,

My two cents. Apologies if this is well known, I am not sure I fully 
grasped your question...

IMHO, the idea of separating LSA flooding from CSPF computation has 
indeed been a current topic for a while, and when it is tied to the idea 
of offloading the CSPF computation to a dedicated centralized server 
(for example a PCE),  I would guess/say that this is usually scoped and 
applies to the case when one formally decouples the control plane from 
the data plane (thus constructing a LSDB and establishing adjacencies in 
the control plane network and also constructing a separated Traffic 
Engineering Database or TED, which is described via opaque LSAs).

In this particular scenario, the CSPF refers to /applies to the 
dataplane only (as is done in GMPLS/PCE), and one still needs SPF for 
the addresses in the DCN. In other words, OSPF-TE is used to disseminate 
data plane (TE) link/node attribute changes (in addition to what OSFPv2 
already does) and for this establishes routing adjacencies and the PCE 
performs CSPF on the TED, which can be a completely different topology.

However, regarding your question "how different from a PCE", I would say 
these are complementary : first a) the PCE architecture does not specify 
how it obtains the Traffic Engineering Database (TED) to construct the 
directed graph on which it operates (i.e., performs CSPF, usually upon 
request); the PCE does not usually care much about the control plane 
topology and, b) what you refer to "push to each router" and "inject 
entries into the RIB" is completely orthogonal to a PCE.

For a), and as stated previously in the list, a common way is to be a 
passive listener or to sniff LSAs with opaque (MPLS TE, area-wide) or to 
contact a topology server or NMS that has the current topology  (TED). 
In other words, a PCE is a decoupled functional component and the 
protocol (PCEP) only specifies the interface to request path 
computations. Even if one uses a PCE and a lightweight LSA flooding 
protocol, SPF still needs to be executed by nodes to "forward" control 
packets, usually using the uncontrained shortest IP route. For b) note 
that, as of now, there is no standard way by which a PCE can configure 
the dataplane by itself. By "configure the dataplane" one can mean to 
"trigger" the establishment of LSPs via RSVP-TE signaling, or configure 
the cross-connects via OpenFlow or to set up state in the datapath 
(could even be configuring the RIB), somehow.

Recently, Ed has started work in stateful PCE, and it is possible that 
in the future it will have the capability to "command" the establishment 
of connections.

In summary, I see the (generic) relationship between PCE and IRS in two 
main ways:

* As a means to communicate / obtain the TED, typically constructed via 
OSPF-TE opaque LSAs. This would be an alternative to existing methods / 
current practice. Another main driver for this is the Hierarchical PCE 
(H-PCE) in case a parent PCE needs to know about an (aggregated) 
topology within a (child) domain, since parent / child PCEs may not be 
in the same IGP area.
In this sense, and as stated in the list, for this, other considered 
solutions are BGPLS / north bound interfaces or to use notify (PCNtf) 
messages wrapping TE LSAs for this.

* As a means to define data plane state (much like OpenFlow) once a Path 
has been computed.

Imho these are two areas which the PCE architecture and protocol do not 
currently cover and in which an architecture such as IRS could be helpful.

Hope this helps (a little!)

Best regards

Ramon

-- 
Ramon Casellas, Ph.D.
Research Associate - Optical Networking Area --http://wikiona.cttc.es
CTTC - Centre Tecnològic de Telecomunicacions de Catalunya, PMT Ed B4
Av. Carl Friedrich Gauss, 7 - 08860 Castelldefels (Barcelona) - Spain
Tel.: +34 93 645 29 00 -- Fax. +34 93 645 29 01