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