Re: [irs-discuss] IRS comments

["Dutta, Pranjal K (Pranjal)" <[e-mail]>]

I believe if IRS needs to address centralized SPF compute then it needs to be a generic approach, irrespective of whether a topology offers LFA/MRT. Thus I see a limited scope since FIB convergence would be a major concern in general, although this is a too early statement to make. As I mentioned I would be very cautious on such approach.

Thanks,
Pranjal 

-----Original Message-----
From: Alia Atlas [mailto:[e-mail]] 
Sent: Thursday, August 16, 2012 7:11 PM
To: Dutta, Pranjal K (Pranjal)
Cc: Ramon Casellas; [e-mail]
Subject: Re: [irs-discuss] IRS comments

If there are always IP-FRR alternates that can be used and only a
single covered failure has happened, then the slow path reconvergence
needn't impact traffic (ignoring the issue of u-loops which we do
understand how to handle).  As for MRT, the advantage is that it
guarantees there'll always be an alternate, unlike LFA.  Some method
has to be used to get that level of coverage - depending on how bad
the FIB convergence times would be.

Alia

On Thu, Aug 16, 2012 at 10:06 PM, Dutta, Pranjal K (Pranjal)
<[e-mail]> wrote:
>
> IP-FRR/LFA can mitigate one aspect of the problem but most of FIB convergence issues in FRR based solutions arise rather during slow
> path convergence after a fast failover. When SPF recompute after
> the FRR switch requires touching the flows again (e.g SPF recompute
> chose a new primary next-hop) then tricks in FIB convergence matters.
> So I would be a bit cautious...MRT etc may not be available in all
> topologies.
>
> Thanks,
> Pranjal
>
> -----Original Message-----
> From: Alia Atlas [mailto:[e-mail]]
> Sent: Thursday, August 16, 2012 6:50 PM
> To: Dutta, Pranjal K (Pranjal)
> Cc: Ramon Casellas; [e-mail]
> Subject: Re: [irs-discuss] IRS comments
>
> On Thu, Aug 16, 2012 at 7:41 PM, Dutta, Pranjal K (Pranjal)
> <[e-mail]> wrote:
>> 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.
>
> [Alia] What it could accomplish is allowing other types of algorithms
> than simple SPF for computing routes.   As for FIB convergence, this
> is certainly a concern.  I do think that fast-reroute technology could
> be used to mitigate the problem - but only really for single failures.
>
>> 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:[e-mail]]
>> Sent: Thursday, August 16, 2012 9:58 AM
>> To: Dutta, Pranjal K (Pranjal)
>> Cc: Alia Atlas; [e-mail]
>> 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.: [phone] -- Fax. [phone]
>>
>>
>>