Question about Reoptimization draft-ietf-ccamp-loose-path-reopt
Faisal Aslam <faisal@telecom.lth.se> Tue, 15 November 2005 13:31 UTC
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec0tz-0007da-Jf for ccamp-archive@megatron.ietf.org; Tue, 15 Nov 2005 08:31:12 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24560 for <ccamp-archive@ietf.org>; Tue, 15 Nov 2005 08:30:39 -0500 (EST)
Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec1B4-0004M8-4S for ccamp-archive@ietf.org; Tue, 15 Nov 2005 08:49:00 -0500
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1Ec0gK-000FbC-0V for ccamp-data@psg.com; Tue, 15 Nov 2005 13:17:04 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0
Received: from [130.235.18.10] (helo=anyida.tts.lth.se) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1Ec0gI-000Faw-K8 for ccamp@ops.ietf.org; Tue, 15 Nov 2005 13:17:03 +0000
Received: from [192.168.2.111] (lina23.tts.lth.se [130.235.18.83]) by anyida.tts.lth.se (8.9.3/8.9.3) with ESMTP id OAA25685 for <ccamp@ops.ietf.org>; Tue, 15 Nov 2005 14:17:18 +0100 (MET)
Message-ID: <4379D1D4.9070202@telecom.lth.se>
Date: Tue, 15 Nov 2005 14:17:24 +0200
From: Faisal Aslam <faisal@telecom.lth.se>
Reply-To: faisal@telecom.lth.se, faisal@lums.edu.pk
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ccamp@ops.ietf.org
Subject: Question about Reoptimization draft-ietf-ccamp-loose-path-reopt
References: <01dd01c5e92d$56df92e0$d501a8c0@Puppy>
In-Reply-To: <01dd01c5e92d$56df92e0$d501a8c0@Puppy>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Content-Transfer-Encoding: 7bit
Hi, I want to know that if a border router is working in "Mid-point explicit notification mode" and a link or node has to go down due to maintenance reasons. Then why not the mid-point can reoptimize the (sub portion of) path locally "without" notifying to the ingress node? The draft says in above case ingress MUST decided to reoptimize (no other choice) then why to wait for ingress decision in the first place and not to perform reoptimization locally? I think that the local node can remember the next-loose-hop node with which the path was originally signaled and later, in the event of local maintenance it should reoptimized without involving ingress (hence save signaling/time). Faisal
- Promoting 3946bis to WG status Adrian Farrel
- Question about Reoptimization draft-ietf-ccamp-lo… Faisal Aslam