[OSPF] FW: [Teas] Architectural question about resource-scheduled LSPs

"Acee Lindem (acee)" <acee@cisco.com> Thu, 23 July 2015 16:29 UTC

Return-Path: <acee@cisco.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id BAE1A1A1AD0 for <ospf@ietfa.amsl.com>; Thu, 23 Jul 2015 09:29:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Y-noGQB1L7LZ for <ospf@ietfa.amsl.com>; Thu, 23 Jul 2015 09:29:41 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B8A01A01FC for <ospf@ietf.org>; Thu, 23 Jul 2015 09:29:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4628; q=dns/txt; s=iport; t=1437668982; x=1438878582; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=C0fTi8srNXtLph0d05I95imtlAQXFeS1z5zP4F3seWk=; b=NFHStW/01rQcYvRnzzcdlTWJD6djpwXoDz9xx0n04iQE6ZvOHRwRVMPG jCM1MLEfD7Q/1qcJ2l2nH4gnvICsO8THvC5kkJl3VJrcjy21PQExME6VV VwJX9p4BqMfH1H6QHVMykz6vw3Oeeai6+WuN0AfTnOR8xATyYaW12I/ce Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.15,531,1432598400"; d="scan'208";a="171700065"
Received: from alln-core-4.cisco.com ([]) by alln-iport-5.cisco.com with ESMTP; 23 Jul 2015 16:29:41 +0000
Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com []) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t6NGTeLu000333 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <ospf@ietf.org>; Thu, 23 Jul 2015 16:29:40 GMT
Received: from xmb-aln-x06.cisco.com ([]) by xhc-rcd-x06.cisco.com ([]) with mapi id 14.03.0195.001; Thu, 23 Jul 2015 11:29:40 -0500
From: "Acee Lindem (acee)" <acee@cisco.com>
To: OSPF WG List <ospf@ietf.org>
Thread-Topic: [Teas] Architectural question about resource-scheduled LSPs
Thread-Index: AdDFThc4ydjkU0GLSi+JbUZsECvfLAARXeMA
Date: Thu, 23 Jul 2015 16:29:39 +0000
Message-ID: <D1D6CE72.2966A%acee@cisco.com>
References: <061d01d0c54e$9243c420$b6cb4c60$@olddog.co.uk>
In-Reply-To: <061d01d0c54e$9243c420$b6cb4c60$@olddog.co.uk>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <61AD2C1D797E8F4CB8344B4FFB02BB25@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/bIVDaoJOOmIW09GQgY4yStaOSRk>
Subject: [OSPF] FW: [Teas] Architectural question about resource-scheduled LSPs
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jul 2015 16:29:45 -0000

FYI - with respect to yesterday’s OSPF presentation on TE advertisement of
time-based bandwidth, the work in MPLS and TEAS would need to precede it.

On 7/23/15, 3:50 PM, "Teas on behalf of Adrian Farrel"
<teas-bounces@ietf.org on behalf of adrian@olddog.co.uk> wrote:

>Having listened to the two presentations on scheduled LSPs in PCE and one
>TEAS I think we need to do some architectural work and make sure we are
>all on
>the same page.
>This work probably needs to be squared off across the two WGs and
>possibly also
>The architectural question is "Where is future scheduled resource
>data held?"
>The options are:
>i. Solely in a centralised DB
>ii. In several distributed DBs that might be periodically synchronised
>iii. Distributed into the network
>iv. Some combination of the above.
>In the old world, the management system held all information about
>in the network. Such management systems were able to schedule connection
>establishment as well since they had a full view of all resources and all
>In MPLS/GMPLS, the pendulum swung. Connection state was held in the
>network and
>not widely known. Only current resource availability was distributed. In
>systems, scheduled connections required a management system that could
>the current resource availability and plan the scheduled connections. But
>approach was vulnerable to connections set up by other entities (in a
>distributed manner) that might "steal" resources needed for a planned
>One of the proposed solutions to this problem is that scheduled state is
>distributed into the network by signaling. That is, an RSVP Path message
>includes the timing parameters and the resources can be reserved by the
>devices for use at the specified time. The disadvantages of this approach
>that the network nodes have to have per-resource time-based databases
>(which may
>be quite complex), and that other nodes in the network (such as other
>nodes, or PCEs) do not know about the future reservations.
>The answer to the second point is to report the future reservations
>either in
>PCEP or in the IGP. Doing it in the IGP means that every node in the
>network can
>see the future reservations, but may have an interesting scaling impact.
>it in PCEP means the PCE is in synch with the network, but doesn't help
>LSRs so implies a PCE-controlled scheduling system.
>At this point we might ask why, if the resource scheduling is controlled
>by the
>PCE, we need to distribute the scheduling information in the network. Why
>just leave the time-based TED in the PCE?
>That reduces us to adding time parameters to the PCReq, but no changes to
>PCInitiate message. The PCRep might have some time-based stuff for
>etc. But, this approach would have no changes to the RSVP messages.
>The above is me just rambling on the topic a bit, but it seems that we
>need to
>get all of this work on the same page and agree the architecture of what
>we are
>trying to build.
>Thanks for listening,
>Teas mailing list