Re: [irs-discuss] IRS comments

[Ramon Casellas <[e-mail]>]

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.: [phone] -- Fax. [phone]