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

From: "James M. Polk" <[email-masked]>
Date: Wed, 01 Nov 2006 13:54:09 -0600

WG

I recommend those that are subscribed to the [email-masked] mailer pay 
attention for any negative comments about this recharter, and in fact the 
longevity of this WG as a whole.  Rumors are that *some* want this WG to go 
away very soon.

I believe the discussion about this will NOT be on the WG list, but on the 
[email-masked] mailer (which I recommend you subscribe to if you want to be 
part of any discussions about this WG).

As with all things IETF, few controversial ideas progress without positive 
comments and feedback.

>To: [email-masked]
>From: IESG Secretary <[email-masked]>
>Date: Wed, 01 Nov 2006 13:59:52 -0500
>Cc: Kimberly King <[email-masked]>, Scott Bradner <[email-masked]>,
>         [email-masked]
>Subject: [Ieprep] WG Review: Recharter of Internet Emergency Preparedness
>         (ieprep)
>
>A modified charter has been submitted for the Internet Emergency
>Preparedness (ieprep) working group in the Real-time Applications and
>Infrastructure Area of the IETF. The IESG has not made any
>determination as yet. The modified charter is provided below for
>informational purposes only. Please send your comments to the IESG
>mailing list ([email-masked]) by November 7th.
>
>+++
>
>Internet Emergency Preparedness (ieprep)
>=========================================
>
>Current Status: Active Working Group
>
>Chair(s):
>Scott Bradner <[email-masked]>
>Kimberly King <[email-masked]>
>
>Real-time Applications and Infrastructure Area Director(s):
>Jon Peterson <[email-masked]>
>Cullen Jennings <[email-masked]>
>
>Real-time Applications and Infrastructure Area Advisor:
>Jon Peterson <[email-masked]>
>
>Mailing Lists:
>General Discussion: [email-masked]
>To Subscribe: [email-masked]
>In Body: subscribe ieprep
>Archive: http://www.ietf.org/mail-archive/web/ieprep/index.html
>
>Description of Working Group:
>
>Effective telecommunications capabilities are imperative to facilitate
>immediate recovery operations for serious emergency events including
>natural disasters (e.g., hurricanes, floods,
>earthquakes) and those created by man (e.g., terrorist attacks, combat
>situations or wartime events). In addition, related capabilities should be
>operative in normal command and control operations of military services,
>which often have timeliness requirements even in peacetime.
>
>Disasters can happen any time, any place, unexpectedly. Quick response
>for recovery operations requires immediate access to any
>telecommunications capabilities at hand. These capabilities include:
>conventional telephone, cellular phones, and Internet access via online
>terminals, IP telephones, and wireless PDAs. The commercial
>telecommunications infrastructure is rapidly evolving to Internet-based
>technology. Therefore, the Internet community needs to consider how it can
>best support emergency management and recovery operations.
>
>The IEPREP WG will address proactive measures to congestion and recovery
>from various outages using three perspectives:
>
>1. A commercial (i.e., or public) telecommunications infrastructure
>
>2. An enterprise or governmental/military telecommunications
>infrastructure that retains sole administration of its own network
>resources
>
>3. A governmental/military telecommunications infrastructure that
>combines private resources and leverages public infrastructure.
>
>Now that the initial documents describing the broad problem space and its
>salient characteristics have been completed, new efforts will focus on
>specific requirements and solutions, such as those pertaining to the
>governmental/military sector. The following are specific examples that can
>satisfy the interests of governmental/military (and potentially,
>commercial/public/enterprise) emergency communications:
>
>1. Under emergency circumstances, some countries require civil networks
>to distinguish sessions based on the userA-s indication of precedence.
>The network can use the precedence information to give priority to some
>sessions over others, up to and including preemption of lower-precedence
>sessions. In many countriesA- governmental networks, the capabilities
>needed to support precedence-based preferential treatment are requirements
>on the equipment and services used to build those networks.
>As Internet-based technology continues to expand into civil and government
>networks, requirements for precedence-based capabilities will need to be
>developed. IEPREP will document these requirements as they pertain to
>technologies of interest to IETF.
>
>2. Specific countries may have additional considerations that define the
>context in which they implement session precedence and preemption. For
>example, network ownership constraints (which may differ from commercial
>deployments), communities of interest including dial-plan considerations,
>encryption assumptions and any limitations arising from differing security
>levels, etc. that should be described before mechanisms can be proposed.
>IEPREP should document the context for implementing solutions. In
>addition, specific solutions must be developed when appropriate.
>
>3. While voice was the driving application for IEPREP in the past,
>preferential treatments will need to be applied to all applications
>essential to emergency communications. Preferential treatment must address
>robustness of both voice and non-real-time applications that share the
>same infrastructure. The IEPREP WG should document the preferential
>treatment mechanisms that are appropriate for any essential
>communications.
>
>In the IETF, considerations for treatment and security of emergency
>communications stretch across a number of working groups, mostly in the
>RAI Area, notably including the various voice/video signaling working
>groups, instant messaging, and QoS signaling. IEPREP will cooperate
>closely with these groups and with those outside of the IETF such as
>various ITU-T study groups. In addition, IEPREP will pursue subject matter
>experts (e.g., security) for specification review if such expertise does
>not exist within the working group in order to ensure continued high
>quality specifications.
>
>If there is an existing group that can extend a protocol or mechanism,
>IEPREP will generate only a requirements document for those groups to
>evaluate. If there is not an existing group that can extend a protocol or
>mechanism, IEPREP will prepare requirements and discuss the extension of
>that protocol/mechanism or protocols/mechanisms within IEPREP. Before this
>working group undertakes any new protocol development, a recharter is
>required.
>
>Goals and Milestones:
>
>Done Submit initial I-D of Requirements Done Submit initial I-D of
>Framework Done Submit initial I-D of Recommendations BCP Done Produce an
>Requirements I-D to IESG for publication as an
>      Informational RFC
>Done Submit Framework I-D to IESG for publication as an Informational RFC
>Dec 06 Submit an initial I-D of Requirements of Government/Military
>      Networks for Precedence and Preemption Dec 06 Submit an initial I-D
>of ETS Terminology. This document should
>      define ieprep related terms (e.g., ETS, GETS, MLPP) and explain their
>
>      relationships and how they have been used in existing RFCs Dec 06
>Submit an initial I-D of Deployment Considerations of Precedence
>      and Preemption on Government/Military Networks. This document should
>      clarify the context that Government/Military requirements must
>operate.
>Mar 07 Submit final I-D of Requirements of Government/Military Networks
>      for Precedence and Preemption to IESG for publication as an
>      Informational RFC
>Mar 07 Submit final I-D of ETS Terminology to IESG for publication as an
>      Informational RFC.
>Jul 07 Submit an final I-D of Deployment Considerations of Precedence
>      and Preemption on Government/Military Networks to IESG for
>publication
>      as an Informational RFC.
>Aug 07 Submit an initial I-D of Mechanisms for Precedence and Preemption
>      to be used by Government/Military Networks Sep 07 Submit final I-D of
>Mechanisms for Precedence and Preemption to
>      be used by Government/Military Networks to IESG for publication as a
>BCP Dec 07 The working group will discuss re-chartering if additional
>      efforts are agreed upon by the WG (for example, work items related to
>
>      protocols outside existing WGs).
>
>_______________________________________________
>Ieprep mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ieprep

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 02 Nov 2006 12:48:04 -0600

It appears this message from Sam didn't make it to the ieprep list, even 
though it <[email-masked]> is a cc.

For those of you who care, there have already been a few folks comment on 
the <[email-masked]> list agreeing with Sam.

>From: Sam Hartman <[email-masked]>
>To: [email-masked]
>Date: Wed, 01 Nov 2006 16:34:20 -0500
>Subject: Re: WG Review: Recharter of Internet Emergency Preparedness (ieprep)
>
>[I could not find the ITU's liaison to the IETF.  Scott, if such
>exists, I'd appreciate you forwarding this to them.]
>
>
>Hi.
>
>I'm speaking here as an individual.  I'd like to build consensus for
>my position both within the IESG and within the community, but I
>realize that if I fail to build that consensus, I cannot make this
>objection as a single IESG member.
>
>I don't believe the new charter of ieprep working group belongs in the
>IETF.  I understand why we chartered it here, and I believe that by
>doing as much work as we have done so far in the IETF, we have done
>something useful.  We've described the broad problem and have helped
>to explain how it fits in the Internet context.  That was an important
>thing for us to do.
>
>However the work that remains belongs somewhere else--probably the
>ITU-T.  I propose that we work with ITU to see if they are interested
>in the work and if so, use this as an opportunity to foster
>cooperation with work going to the ITU.
>
>
>In order for the proposed charter to be successful, the working group
>will need to go far outside the IETF's normal technical mandate and
>venture into the space of network design to come up with requirements
>documents.  The technical aspects of this problem are only one of the
>things going into successful requirements.
>
>Based on my limited knowledge I believe that the ITU is in a better
>position than the IETF to specify requirements and mechanisms for
>national and government telecommunications networks.  I think we
>should let them do their job just as we ask them to let us do our job
>and to design the technical protocols that are increasingly being used
>on those networks.
>
>Naturally, the IETF should make any necessary modifications to IETF
>protocols to implement IEPREP work regardless of where it takes place.
>
>The main argument I've heard throughout the existence of ieprep for
>why it needed to happen in the IETF is that if it happens elsewhere,
>they'll do something we don't like or do it wrong.  Perhaps that was
>once a valid argument.  However, I think we have enough of the details
>of technical approaches that we find appropriate documented that we
>can give sufficient input to another body on what approaches work on
>the Internet.  I would assume we'd ask people working in this space to
>take a look at the existing ieprep output, RFC 4542, RFC 4411,
>draft-ietf-tsvwg-vpn-signal-preemption and other appropriate
>documents.
>
>I think that given this input another group could understand what
>works well on the internet and could work both on requirements related
>to the technology as well as the overall system architecture so we end
>up with deployable solutions at national and governmental levels.
>
>In addition, I believe that since the first part of the ieprep work
>happened here, we would be in a good position to work with whatever
>standards body did the work to scope the charter to favor technologies
>that would work well on the Internet.
>
>
>Thanks for your consideration,
>
>--Sam
>
>Ietf mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ietf

---

From: Janet P Gunn <[email-masked]>
Date: Thu, 2 Nov 2006 16:48:05 -0500

----- Forwarded by Janet P Gunn/FED/CSC on 11/02/2006 04:47 PM -----

ken carlberg <[email-masked]> wrote on 11/02/2006 01:58:01 PM:

> Sam,
>
> One of the objectives of the work produced by IEPREP was to lay down
> the ground work and put together a baseline set of requirements to
> start with when considering solutions.  Our intention was that the
> baseline then becomes a starting point where more specific
> requirements can be put forth.  Outside of this, solutions were
> definitely out of scope.
>
> My understanding is that there are others that now wish to present
> some more specific requirements and potential solutions that do not
> fall into the scope of other working groups.  So the proposed re-
> charter looks to be a natural extension to what has been done.
>
> Interestingly enough, the work that you mention below in your
> original posting...
>
> <snip>
> "I would assume we'd ask people working in this space to
> documents."
> ... rfc-4542, rfc-4411, and draft -ietf-tsvwg-vpn-signal-preemption
> (along with some other related work) has actually not been done in
> IEPREP because the group was not allowed to consider solutions.
> Instead, some of the work has been pushed to TSVWG, to the groans
> and sometimes confusion of some of the participants of that group,
> who wondered what the subject of prioritization had to do with
> TSVWG.  Part of the revised charter is meant to remove this obstacle.
>
> Also, as Scott Brimm has mentioned, there is a proposed liaison from
> the ITU to work with the IETF, with one of the working groups of
> interest being IEPREP.  It would seem odd to close down the group
> and punt the subject to them when they are approaching "us" for
> assistance  If IEPREP is closed, does that mean the subject gets
> pushed over to TSVWG?
>
> -ken
>

---

From: Janet P Gunn <[email-masked]>
Date: Thu, 2 Nov 2006 16:49:54 -0500

----- Forwarded by Janet P Gunn/FED/CSC on 11/02/2006 04:49 PM -----

Sam Hartman <[email-masked]> wrote on 11/02/2006 02:30:43 PM:

> >>>>> "James" == James M Polk <[email-masked]> writes:
>
>     James> At 12:41 PM 11/2/2006 +0200, Pekka Savola wrote:
>     >> On Wed, 1 Nov 2006, Sam Hartman wrote: > I don't believe the
>     >> new charter of ieprep working group belongs in the > IETF.  I
>     >> understand why we chartered it here, and I believe that by >
>     >> doing as much work as we have done so far in the IETF, we have
>     >> done > something useful.  We've described the broad problem and
>     >> have helped > to explain how it fits in the Internet context.
>     >> That was an important > thing for us to do.
>     >>
>     >> I think I'll agree with Sam.
>
>     James> I do not agree with Sam
>
>     >> Having looked at the output of the WG, it already seems to
>     >> include a couple of useful framework documents and about 4
>     >> requirements documents.
>
>     James> the framework RFCs are for within a single public domain.
>     James> The other RFCs are requirements based.
>
>     James> There is no architecture guidelines docs or peering
>     James> guidelines or the like.
>
> Why does that belong in the IETF?  RFC 2418 gives a good set of things
> to consider for determining whether work belongs in the IETF.  I will
> try to write up a guideline by guideline analysis of this work,
> although when I briefly examine the guidelines my continuing reaction
> is that the work probably does not belong in the IETF.  If you have
> time to write up such an analysis I'd be interested in what you come
> up with.
>
>     >> This should already provide sufficient information how to
>     >> continue the work.
>
>     James> continue the work.... where? by who? by another SDO?  Why?
>
>
> My proposal is ITU-T--probably SG 13, although I don't understand ITU
> internals enough to know for sure that's the right place.
>
> Obviously, this assumes they want to do the work.
>
> To propose concrete action, I think the IETF should draft a liaison
> statement for action to the ITU asking for them to comment on whether
> they see any current conflicts and on whether there are parts of this
> work they would be interested in picking up.  Such liaisons are not
> uncommon when appropriate; we had such an exchange with IEEE when the
> trill working group was formed.
>
>
> If the ITU says that they're not interested in these aspects of the
> work, and no one else makes an alternative proposal, then I would not
> object to the work being chartered in the IETF.  However if the ITU
> would be interested in working on this problem space (or especially is
> already work on this problem space), we need to carefully ask
> ourselves why each aspect of the work being done in the IETF belongs
> here.
>
>
> --Sam
>

---

From: Janet P Gunn <[email-masked]>
Date: Thu, 2 Nov 2006 16:51:04 -0500

----- Forwarded by Janet P Gunn/FED/CSC on 11/02/2006 04:50 PM -----

Sam Hartman <[email-masked]> wrote on 11/02/2006 02:45:16 PM:

> >>>>> "ken" == ken carlberg <[email-masked]> writes:
>
>     ken> Sam, One of the objectives of the work produced by IEPREP was
>     ken> to lay down the ground work and put together a baseline set
>     ken> of requirements to start with when considering solutions.
>     ken> Our intention was that the baseline then becomes a starting
>     ken> point where more specific requirements can be put forth.
>     ken> Outside of this, solutions were definitely out of scope.
>
>     ken> My understanding is that there are others that now wish to
>     ken> present some more specific requirements and potential
>     ken> solutions that do not fall into the scope of other working
>     ken> groups.  So the proposed re-charter looks to be a natural
>     ken> extension to what has been done.
>
>     ken> Interestingly enough, the work that you mention below in your
>     ken> original posting...
>     ken> ... rfc-4542, rfc-4411, and draft
>     ken> -ietf-tsvwg-vpn-signal-preemption  (along with some other
>     ken> related work) has actually not been done in IEPREP because
>     ken> the group was not allowed to consider solutions.  Instead,
>     ken> some of the work has been pushed to TSVWG, to the groans and
>     ken> sometimes confusion of some of the participants of that
>     ken> group, who wondered what the subject of prioritization had to
>     ken> do with TSVWG.  Part
>
> I think the work you cite belongs in tsvwg.  AT least 4542 and
> vpn-signaling-preemption.
>
>     ken> of the revised charter is meant to
>     ken> remove this obstacle.
>
> Which work would be permitted under the revised charter that is
> currently udone elsewhere?  I may have more concerns about the revised
> charter than I thought I did.
>
>     ken> Also, as Scott Brimm has mentioned, there is a proposed
>     ken> liaison from the ITU to work with the IETF, with one of the
>     ken> working groups of interest being IEPREP.  It would seem
>     ken> odd to close down the group and punt the subject to them when
>     ken> they are approaching "us" for assistance  If IEPREP is
>     ken> closed, does that mean the subject gets pushed over to TSVWG?
>
>
> that rather depends on what question they're asking, now doesn't it?
> IF they're asking for enhancements to RSVP to deal with some ETS
> issues, then yes, I'd hope the work would be done in tsvwg.  That way,
> ETS requirements can be balanced against other requirements.  If they
> want to change SIP, I'd hope that it would go through sipping and
> eventually sip.
>
>
> If they want us to do non-protocol work closer to 4542, then perhaps
> we need a WG to do it in.
>
> --Sam
>
>

---

From: Janet P Gunn <[email-masked]>
Date: Thu, 2 Nov 2006 16:51:53 -0500

----- Forwarded by Janet P Gunn/FED/CSC on 11/02/2006 04:51 PM -----

ken carlberg <[email-masked]> wrote on 11/02/2006 03:03:15 PM:

> I mentioned the above as examples, not as a case-by-case examination
> of what should or should not be in IEPREP.  But along those lines,
> rfc-4542 (titled "Implementing an Emergency Telecommunications
> Service"), where ETS was first established in IEPREP and the draft
> deals with priority and preemption, seems odd to me to be in TSVWG.
> But if you feel differently, then we agree to disagree.
>
> I am not speaking of any specific work other than what has been
> discussed in the proposed re-charter.  to consider otherwise is to go
> beyond what I stated.
>
> we will have to wait to see what they request.  all I stated was that
> they were coming to us and that it was odd to close down a group they
> were interested in working with.  Anticipating hypotheticals are not
> useful because they can put us down a rat hole that may or may not
> have substance.
>
> -ken
>
>

---

From: Janet P Gunn <[email-masked]>
Date: Thu, 2 Nov 2006 16:53:10 -0500

----- Forwarded by Janet P Gunn/FED/CSC on 11/02/2006 04:52 PM -----

Pekka Savola <[email-masked]> wrote on 11/02/2006 04:16:01 PM:

> On Thu, 2 Nov 2006, James M. Polk wrote:
> > >Having looked at the output of the WG,
> > >it already seems to include a couple of useful framework documents and
> > >about 4 requirements documents.
> >
> > the framework RFCs are for within a single public domain.  The
> other RFCs are
> > requirements based.
> >
> > There is no architecture guidelines docs or peering guidelines or the
like.
>
> I guess by 'architecture guidelines' you refer to inter-domain
> guidelines as the framework RFCs already seem to deal at least to some
> extent with a single domain.  If you don't, you may mean something
> that operators would use.  It's not clear if one-size-fits-all
> guidelines could be made, or if this would be right place to try to
> seek it.
>
> Is there already sufficient experience of getting multi-domain work?
> AFAICS, this hasn't generally been considered an easily solvable
> problem at an operational level.
>
> Peering guidelines likely don't belong to the IETF, or has there been
> successful precendent for that kind of work in the past?  (I could say
> some examples, but I don't think those were very succesful, and those
> were from OPS area)
>
> Even if this work was in the scope of IETF, at least these two seem
> more like subjects to be pursued in the Ops&Mgmt area.
>
> > >This should already provide
> > >sufficient information how to continue the work.
> >
> > continue the work.... where? by who? by another SDO?  Why?
>
> Other SDOs if they're willing.  Organizations that actually want to
> deploy this stuff (if those exist in sufficient degree).  Vendors who
> want to push for this stuff.  That is to say -- is there enough
> deployment (and understanding what works and is deployable and what
> isn't) to justify more IETF work on the subject _right now_ ?
>
> > >Overprovisioning and intra-domain TE seems to have been a
popularapproach,
> >
> > in which IEPREP doc was "Overprovisioning" and "intra-domain TE "
discussed?
>
> draft-ietf-ieprep-domain-frame-07.txt, RFC4190, RFC43745 to name a
> few.
>
> > >but apart from that, where has this been  deployed and how?
> > >
> > >Maybe we should let ITU, vendors, and/or deploying organizations to
> > >apply the existing techniques
> >
> > What "techniques" have been defined?
>
> The framework documents talk a lot about certain kinds of DSCP PHBs,
> mappings between PSTN and VoIP, a particular end-to-end priority
> field, MPLS-like traffic engineering, access-controls to prevent
> DoSing priority treatment, active queue management techniques, drop
> priority techniques, etc. -- this already seems to be a significant
> toolbox.  It is not clear to me to what extent these have been used
> and do the job set out for IEPREP.  And if not, is the lack of use due
> to people solving the problem in other ways (or not at all) rather
> than the lack of mechanisms?
>
> --
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>

---

From: "Dolly, Martin C, ALABS" <[email-masked]>
Date: Thu, 16 Nov 2006 06:00:53 -0600

Pekka,

At least two carriers, AT&T and Verizon support, "An EF DSCP for
Capacity-Admitted Traffic", Fred Baker, 6-Oct-06

Martin  

-----Original Message-----
From: Pekka Savola [mailto:[email-masked]] 
Sent: Thursday, November 16, 2006 2:32 AM
To: Fred Baker
Cc: Sam Hartman; [email-masked]; [email-masked]; Scott Bradner
Subject: Re: WG Review: Recharter of Internet Emergency Preparedness
(ieprep)

On Wed, 15 Nov 2006, Fred Baker wrote:
> We also specifically addressed their requirements (in tsvwg)
operationally:
> 
> >http://www.ietf.org/rfc/rfc4594.txt
> >4594 Configuration Guidelines for DiffServ Service Classes. J.
> >     Babiarz, K. Chan, F. Baker. August 2006. (Format: TXT=144044
bytes)
> >     (Status: INFORMATIONAL)
> >
> >http://tools.ietf.org/html/draft-ietf-tsvwg-diffserv-class-aggr
> >  "Aggregation of DiffServ Service Classes", Kwok Ho Chan, 22-Oct-06
> >and
> >http://tools.ietf.org/html/draft-baker-tsvwg-admitted-voice-dscp
> >  "An EF DSCP for Capacity-Admitted Traffic", Fred Baker, 6-Oct-06
> 
> The last two are in last call and in discussion in tsvwg respectively.

All of these documents are, or are aimed at Informational.  I do not 
see how those could define DSCP codepoints or behaviour -- doing so 
requires Standards Action and certain codepoint pools are reserved for 
local/private use (which specifying them is not).  I wonder how wide 
IETF or operator consensus is behind this work.

---

From: Fred Baker <[email-masked]>
Date: Thu, 16 Nov 2006 20:22:29 -0800

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 <[email-masked]>
> 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