some comments on I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
Loa Andersson <loa@pi.nu> Fri, 01 August 2008 07:47 UTC
Return-Path: <owner-ccamp@ops.ietf.org>
X-Original-To: ietfarch-ccamp-archive@core3.amsl.com
Delivered-To: ietfarch-ccamp-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1FF128C3A1 for <ietfarch-ccamp-archive@core3.amsl.com>; Fri, 1 Aug 2008 00:47:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.472
X-Spam-Level:
X-Spam-Status: No, score=-1.472 tagged_above=-999 required=5 tests=[AWL=-1.035, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aweYz+MYSb1S for <ietfarch-ccamp-archive@core3.amsl.com>; Fri, 1 Aug 2008 00:47:11 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 74B0328C108 for <ccamp-archive@ietf.org>; Fri, 1 Aug 2008 00:47:10 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1KOpAM-000BcC-D1 for ccamp-data@psg.com; Fri, 01 Aug 2008 07:35:10 +0000
Received: from [192.71.80.124] (helo=neo.viciousnest.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from <loa@pi.nu>) id 1KOpA7-000BZt-Ji for ccamp@ops.ietf.org; Fri, 01 Aug 2008 07:34:59 +0000
Received: from localhost (localhost [127.0.0.1]) by neo.viciousnest.net (Postfix) with ESMTP id D91683F37B; Fri, 1 Aug 2008 09:34:53 +0200 (CEST)
Received: from neo.viciousnest.net ([127.0.0.1]) by localhost (neo [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22708-02; Fri, 1 Aug 2008 09:34:50 +0200 (CEST)
Received: from [127.0.0.1] (unknown [130.129.23.82]) by neo.viciousnest.net (Postfix) with ESMTP id EE4503F2F0; Fri, 1 Aug 2008 09:34:49 +0200 (CEST)
Message-ID: <4892BC91.7010606@pi.nu>
Date: Fri, 01 Aug 2008 09:34:41 +0200
From: Loa Andersson <loa@pi.nu>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: Attila Takacs <Attila.Takacs@ericsson.com>
CC: ccamp <ccamp@ops.ietf.org>
Subject: some comments on I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
References: <20080707061501.744433A68FD@core3.amsl.com> <48748C72.9080309@pi.nu> <53CCFDD6E346CB43994852666C210E91046A6C5D@esealmw116.eemea.ericsson.se>
In-Reply-To: <53CCFDD6E346CB43994852666C210E91046A6C5D@esealmw116.eemea.ericsson.se>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at viciousnest.net
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
List-ID: <ccamp.ops.ietf.org>
Attila, I have planned respond to this for same time, but did not really had time to get around to it. Attila Takacs wrote: > Hi Loa, > > I assume a part of your comment/question relates to problems with > reversion if LSP setup and holding priorities are mismatched. that would be one case, but not really what i was thinking of > In this > case the worker may be already deleted before the reversion would take > place. This is certainly an interesting question... sure > > ...at a first thought an explicit revertive bit may be used to override > the priorities for LSPs with revertive protection. I've two questions: 1. If revertiveness is the normal procedure, wouldn't it be better to let indicate LSPs that *shouldn't* revert? 2. What I really thought about was, how does revertiveness work with traffic placement policies? Assume that you have a policy that that says you want to optimize the chances to successfully set up an LSP that make a maximum share of some constraints. It could be any constraints, but thinking of it as bw wouldn't wrong. Assume also that you have three different routes form A to B, through C, D and E respectively. Assume that each of the nodes C, D and E has interfaces with constraint of 100. This is of course a very simplified model just to illustrate my point. In order the follow your policy you place traffic on C and E, and leave D free, if there is a request for an LSP that requires 100. So the situation could be: C = 40 occupied, 60 free D = 100 free E = 40 occupied, 60 free now if C fails it makes sense to move the traffic to E: C = failed D = 100 free E = 80 occupied, 20 free If the failure takes some time to repair, there might be a request for a LSP that requires 60, the only possibility is to place on D: C = failed D = 60 occupied, 40 free E = 80 occupied, 20 free Now C comes back up: C = 100 free D = 60 occupied, 40 free E = 80 occupied, 20 free This situation is in accordance with your policy, but if you revert you loose the ability to place any LSPs which requires more than 60 C = 40 occupied, 60 free D = 60 occupied, 40 free E = 40 occupied, 60 free Why would you want to revert in this case? Now there might be some optimization program working in the background, that might move traffic from any of nodes to any of the other, possibly from C to E. I seems to me that running an optimization program is more efficient. /Loa > > Best regards, > Attila > > > -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.nu
- Re: I-D Action:draft-takacs-ccamp-revertive-ps-00… Loa Andersson
- RE: I-D Action:draft-takacs-ccamp-revertive-ps-00… Attila Takacs
- RE: I-D Action:draft-takacs-ccamp-revertive-ps-00… PAPADIMITRIOU Dimitri
- RE: I-D Action:draft-takacs-ccamp-revertive-ps-00… Attila Takacs
- RE: I-D Action:draft-takacs-ccamp-revertive-ps-00… PAPADIMITRIOU Dimitri
- RE: I-D Action:draft-takacs-ccamp-revertive-ps-00… Attila Takacs
- some comments on I-D Action:draft-takacs-ccamp-re… Loa Andersson