Re: [irs-discuss] IRS comments

Alia Atlas <akatlas@gmail.com> Fri, 17 August 2012 02:46 UTC

Return-Path: <akatlas@gmail.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 3294511E80A2 for <irs-discuss@ietfa.amsl.com>; Thu, 16 Aug 2012 19:46:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.515
X-Spam-Level:
X-Spam-Status: No, score=-3.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 MfD92UTzGPyo for <irs-discuss@ietfa.amsl.com>; Thu, 16 Aug 2012 19:46:19 -0700 (PDT)
Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id B7A8E11E808D for <irs-discuss@ietf.org>; Thu, 16 Aug 2012 19:46:18 -0700 (PDT)
Received: by ghbg16 with SMTP id g16so3964528ghb.31 for <irs-discuss@ietf.org>; Thu, 16 Aug 2012 19:46:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=RBixjnJp19WcDk8lxwt4meUYnDeCc3fshY8KaD41ozo=; b=T33yLTDuvD4UtnIqkNp1RwsYE2mTiU796f9Dnhg5kO21Ctw4Y2RL3Jj6DFVIo1PZJU Soa4QXqwjdCYb5ASLRtEB5WnqsD3VkMG5ZjG8++AY4mdfm+k+KBjT60Ze6s4jxtOqj4j zehPx8UHYF4Y1MLwSpmmhfGvCqZK/OGcbbw3kSf7dFlZlxTj0wzZugJwjOUxOhhtQw30 hSokz1cz2L78aoW00BXH7yieod7rOeKYSgvGiIwW1SLc99qGTbf75gbsjKWMWfb7YQeZ zmxKB3Hh522itrVnaFJh5fJWlfCWy/f+SEr68kZSi0y6MY5LBbm45exPKdk7fNDyi4AT 8eQg==
MIME-Version: 1.0
Received: by 10.50.213.106 with SMTP id nr10mr269478igc.58.1345171577942; Thu, 16 Aug 2012 19:46:17 -0700 (PDT)
Received: by 10.50.91.135 with HTTP; Thu, 16 Aug 2012 19:46:17 -0700 (PDT)
In-Reply-To: <C584046466ED224CA92C1BC3313B963E09F22C566D@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> <C584046466ED224CA92C1BC3313B963E09F22C5669@INBANSXCHMBSA3.in.alcatel-lucent.com> <CAG4d1rdsf5Jv38Ama+GW7_GrsBKxgMFhHLGaFRhEwyR3-wrgZQ@mail.gmail.com> <C584046466ED224CA92C1BC3313B963E09F22C566C@INBANSXCHMBSA3.in.alcatel-lucent.com> <CAG4d1rf_j6OTkKTwecRKPywe2RTJTzaDVvzmjERAfxLXnbN3HQ@mail.gmail.com> <C584046466ED224CA92C1BC3313B963E09F22C566D@INBANSXCHMBSA3.in.alcatel-lucent.com>
Date: Thu, 16 Aug 2012 22:46:17 -0400
Message-ID: <CAG4d1reouQtY8j=Gbxz5e1HsRXdoJQPD79J9BjnTuGxJjkO=Ug@mail.gmail.com>
From: Alia Atlas <akatlas@gmail.com>
To: "Dutta, Pranjal K (Pranjal)" <pranjal.dutta@alcatel-lucent.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: Ramon Casellas <ramon.casellas@cttc.es>, "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: Fri, 17 Aug 2012 02:46:26 -0000

Pranjal,

Sure - IRS is to provide an Interface to the Routing System.  If part
of the routing system isn't co-located on the forwarding device, then
it'd be good for the IRS data-models and such to work with it.  That's
hard when it is a moving target.

My point about LFA/MRT/IP-FRR is simply that if the SPF compute is
remote, then that will impact the convergence time.  At that point for
an architecture, there are basically two choices - deal with longer
periods of traffic loss or pre-compute and install alternates to use
in the case of a local failure.   The longer FIB convergence time
could thus be mitigated.

Whether centralized SPF compute is a good idea probably depends
greatly on the use-case and details of the architecture.  I haven't
seen ones that convince me yet, but I haven't been hunting them
either.

Alia

On Thu, Aug 16, 2012 at 10:19 PM, Dutta, Pranjal K (Pranjal)
<pranjal.dutta@alcatel-lucent.com> wrote:
> 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:akatlas@gmail.com]
> Sent: Thursday, August 16, 2012 7:11 PM
> To: Dutta, Pranjal K (Pranjal)
> Cc: Ramon Casellas; irs-discuss@ietf.org
> 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)
> <pranjal.dutta@alcatel-lucent.com> 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:akatlas@gmail.com]
>> Sent: Thursday, August 16, 2012 6:50 PM
>> To: Dutta, Pranjal K (Pranjal)
>> Cc: Ramon Casellas; irs-discuss@ietf.org
>> Subject: Re: [irs-discuss] IRS comments
>>
>> On Thu, Aug 16, 2012 at 7:41 PM, Dutta, Pranjal K (Pranjal)
>> <pranjal.dutta@alcatel-lucent.com> 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: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
>>>
>>>
>>>