Re: [Ieprep] Re: WG Review: Recharter of Internet Emergency Preparedness (ieprep)

Fred Baker <fred@cisco.com> Fri, 17 November 2006 04:22 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkvFQ-0007uc-Qg; Thu, 16 Nov 2006 23:22:40 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkvFO-0007uR-DK; Thu, 16 Nov 2006 23:22:38 -0500
Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkvFN-000277-2M; Thu, 16 Nov 2006 23:22:38 -0500
Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 16 Nov 2006 20:22:36 -0800
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id kAH4MaPJ020943; Thu, 16 Nov 2006 20:22:36 -0800
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kAH4MVOV002057; Thu, 16 Nov 2006 20:22:33 -0800 (PST)
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 20:22:31 -0800
Received: from [10.32.244.221] ([10.32.244.221]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 20:22:30 -0800
In-Reply-To: <200611170313.kAH3DPpY069571@workhorse.brookfield.occnc.com>
References: <200611170313.kAH3DPpY069571@workhorse.brookfield.occnc.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <4FA1B87B-773C-4083-AAF0-5CA990AB5C52@cisco.com>
Content-Transfer-Encoding: 7bit
From: Fred Baker <fred@cisco.com>
Subject: Re: [Ieprep] Re: WG Review: Recharter of Internet Emergency Preparedness (ieprep)
Date: Thu, 16 Nov 2006 20:22:29 -0800
To: curtis@occnc.com
X-Mailer: Apple Mail (2.752.2)
X-OriginalArrivalTime: 17 Nov 2006 04:22:30.0650 (UTC) FILETIME=[FF37B5A0:01C709FF]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2468; t=1163737356; x=1164601356; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20<fred@cisco.com> |Subject:=20Re=3A=20[Ieprep]=20Re=3A=20WG=20Review=3A=20Recharter=20of=20 Internet=20Emergency=20Preparedness=20(ieprep)=20 |Sender:=20; bh=qZv1PZgbRy8ZU91Z24ifacarnk8HXhn/On+3u5n7ouU=; b=A7QT3hzPD5ssi81oz2LhXh88rSGhXDFqCjKbVh4G0tl4DtNXN0trUG+hLq4wcxf6qabptICE KQLt1XT1y3Vy/ZkNLLjgIFT/U49wPrbWXVtJXWgR3J6m431WrsLOJAjy;
Authentication-Results: sj-dkim-8; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim8002 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Cc: "Robert G. Cole" <robert.cole@jhuapl.edu>, Pekka Savola <pekkas@netcore.fi>, ieprep@ietf.org, Kimberly King <kimberly.s.king@saic.com>, Brian E Carpenter <brc@zurich.ibm.com>, Scott Bradner <sob@harvard.edu>, Sam Hartman <hartmans-ietf@mit.edu>, ietf@ietf.org
X-BeenThere: ieprep@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet Emergency Preparedness Working Group <ieprep.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ieprep@ietf.org>
List-Help: <mailto:ieprep-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=subscribe>
Errors-To: ieprep-bounces@ietf.org

What you're describing, in general terms, is MPLS TE. Yes, MPLS TE  
will allow you to use your capacity a little more efficiently.

As I said, not all networks are MPLS, and not all MPLS networks do  
traffic engineering.

The scenario in question is *after* those things have been done.

On Nov 16, 2006, at 7:13 PM, Curtis Villamizar wrote:

>
> In message <5512B961-3280-4EBD-8A0B-275AD43358DE@cisco.com>
> Fred Baker writes:
>>
>> On Nov 16, 2006, at 4:02 PM, Curtis Villamizar wrote:
>>> Preemption in MPLS can be soft preemption (setting aside
>>> differences of opinion about how signaling of soft preempt should
>>> be done for the moment)...
>>>
>>> Even for hard preemption, there is at worst a fall back to IP and
>>> reroute...
>>
>> Those are both options, but IMHO have issues. One can't, for example,
>> fall back and reroute to a different path if the bottleneck where
>> preemption is occurring is the only path to the destination. [...]
>
> One vendor, lets call them vendor A, has solved this using a feature
> they call metric-bias which is a better alternative to soft
> preemption.  MPLS CSPF is influenced so that an effort is made to
> avoid highly utilized links.  If there is no other way, thats where it
> goes.  If there is other traffic (BE) thats what gets clobberred.
>
> But we're way off topic so I won't go into details.
>
>> [big snip]
>>
>> Yes, I'm being extreme, but this topic is about the end cases. And
>> yes, adding more bandwidth is always helpful. It isn't always an
>> option, and under the scenarios in question (in some cases, just say
>> "Armageddon") might be pretty difficult to predict in detail.
>
> Plain IP solutions based on queueing alone work fine if allowing  
> the ETS
> traffic to take the shortest IGP path never congests the ETS traffic
> and never gets too painful for the BE traffic.
>
> Generally MPLS shines relative to plain IP where there is a network
> fault, or many network faults, and capacity remains but may be quite
> limited in part of the topology.  That would be expected to be the
> case in certain situation where an ETS is most needed.
>
> For example, multiple faults occurred and capacity was very
> substantially reduced during and for quite a while after Katrina.
> Some automatic means of best using whatever capacity is available at
> any give time (such as MPLS does) would be a good thing IMHO.
>
> Do you disagree?
>
> Curtis

_______________________________________________
Ieprep mailing list
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep