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
- [Ieprep] WG Review: Recharter of Internet Emergen… IESG Secretary
- [Ieprep] WG Review: Recharter of Internet Emergen… James M. Polk
- [Ieprep] Fwd: Re: WG Review: Recharter of Interne… James M. Polk
- [Ieprep] Re: WG Review: Recharter of Internet Eme… James M. Polk
- [Ieprep] Fw: WG Review: Recharter of Internet Eme… Janet P Gunn
- [Ieprep] Fw: WG Review: Recharter of Internet Eme… Janet P Gunn
- [Ieprep] Fw: WG Review: Recharter of Internet Eme… Janet P Gunn
- [Ieprep] Fw: WG Review: Recharter of Internet Eme… Janet P Gunn
- [Ieprep] Fw: WG Review: Recharter of Internet Eme… Janet P Gunn
- [Ieprep] Re: WG Review: Recharter of Internet Eme… Fred Baker
- Re: [Ieprep] Re: WG Review: Recharter of Internet… Robert G. Cole
- [Ieprep] Re: WG Review: Recharter of Internet Eme… ken carlberg
- Re: [Ieprep] Re: WG Review: Recharter of Internet… Janet P Gunn
- [Ieprep] Re: WG Review: Recharter of Internet Eme… Janet P Gunn
- [Ieprep] Re: WG Review: Recharter of Internet Eme… Fred Baker
- Re: [Ieprep] Re: WG Review: Recharter of Internet… Robert G. Cole
- [Ieprep] Re: WG Review: Recharter of Internet Eme… Fred Baker
- [Ieprep] RE: WG Review: Recharter of Internet Eme… Dolly, Martin C, ALABS
- Re: [Ieprep] Re: WG Review: Recharter of Internet… Janet P Gunn
- RE: [Ieprep] Re: WG Review: Recharter of Internet… Dolly, Martin C, ALABS
- Re: [Ieprep] Re: WG Review: Recharter of Internet… Brian F. G. Bidulock
- RE: [Ieprep] Re: WG Review: Recharter of Internet… Janet P Gunn
- Re: [Ieprep] Re: WG Review: Recharter of Internet… Fred Baker
- Re: [Ieprep] Re: WG Review: Recharter of Internet… Curtis Villamizar
- RE: [Ieprep] Re: WG Review: Recharter of Internet… Dolly, Martin C, ALABS
- Re: [Ieprep] Re: WG Review: Recharter of Internet… Fred Baker
- Re: [Ieprep] Re: WG Review: Recharter of Internet… Fred Baker