Subject: RE: [Ieprep] ieprep-requirements-01 - reqs 1-5 - discussion request

From: "Garrity, Jack" <[email-masked]>
Date: Tue, 12 Nov 2002 07:47:48 -0500

Ken,

ADDENDUM

Some suggested that I add the point that the transit carriers, local
exchange carriers and interexchange carriers, are paid for providing the
NS/EP services. 

~~~ Jack ~~~
Work: 703/676-2358 | Fax: 703/848-0299
Home: 703/278-9250 | Cell: 703/508-0065
E-mail: [email-masked]

-----Original Message-----
From: Garrity, Jack 
Sent: Tuesday, November 12, 2002 7:41 AM
To: 'Ken Carlberg'
Cc: ieprep
Subject: RE: [Ieprep] ieprep-requirements-01 - reqs 1-5 - discussion
request

Ken,

For the scenario you describe, the NS/EP codepoint and NS/EP features take
effect at GETS-capable local exchanges.  Those exchanges serve over X
percent of US-based access lines, where X is on the order of 85 percent or
greater.

Once the call reaches a GETS-capable local exchange or a GETS interexchange
carrier, the NS/EP treatment is carried through to the terminating local
exchanges.  If the terminating local exchange is GETS-capable (same switches
as in the first paragraph), NS/EP features have effect.

I won't guarantee this description entirely.  If this description suffices,
I'll be ready to try to evaluate the content in your original message.

~~~ Jack ~~~
Work: 703/676-2358 | Fax: 703/848-0299
Home: 703/278-9250 | Cell: 703/508-0065
E-mail: [email-masked]

-----Original Message-----
From: Ken Carlberg [mailto:[email-masked]]
Sent: Tuesday, November 12, 2002 7:29 AM
To: Garrity, Jack
Cc: ieprep
Subject: Re: [Ieprep] ieprep-requirements-01 - reqs 1-5 - discussion
request

> I'll try to evaluate your message content after you expand a bit on your
> statement about "the current GETS system doesn't offer any special service
> within a land-line exchange."  

by this I meant that if one were to make a 'local' call within a LEC 
(eg, Brooklyn NY, to Manhattan NY), the NS/EP code point and HPC
services don't take effect until the call signaling goes from the 
origin LEC to the IXC.  further, that the NS/EP call doesn't extend
to the destination end-office.  so things like extended trunk queuing
is not done along the entire path between the originator and the 
destination in the US PSTN.  have I got that right?

-ken

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

---

From: Rex Buddenberg <[email-masked]>
Date: 12 Nov 2002 11:16:13 -0800

Any real world emergency services operation will be transiting multiple
ISPs -- especially counting the local (likely at both ends)
infrastructure where my EMS outfit is its own ISP.  

Consider a municipal fire/police lashup: I have a command center in the
fire department dispatching office that has a LAN with workstations on
it -- situation awareness and command & control is the name of the
game.  Either in-band or out-of-band is a means of in-access for the
public (such as 911 relay).  Being sensible and reading the yet-to-be
drafted BCPs from IEPREP, I make my network redundant (no single points
of failure) and I preserve the connectionless IP layer (making reliable
crossover work).  And I have both an SNMP management system in place to
detect failures as they occur and a trouble ticket system to track
them.  There, I've met the three principles of high availability
engineering.
	Secondly, I've provisioned the police department across town the same
way so I have a backup command center.  

At the router(s), I meet the commercial ISP.  The first thing I want is
diverse paths between the two command centers to complete that high Ao
exercise.  How do I spec that?  In this case, high Ao would probably
trump any QoS requirements -- by the time you meet the Ao needs we have
overprovisioned and Bill W's comments apply.  And this is the analogy
that, I think, Ran is fishing for.  [??]

Now in order to do the fire/police department's emergency services work,
I need to reach my mobile platforms -- in particular the deployed
engines.  To get there, I have my ISP provide wireless POPs around town
(heaven forbid that they be for my exclusive use -- my taxpayers don't
have that kind of money.  Besides, I want the stuff used daily so we all
know how ... not just in emergencies).  The terrestrial WAN can again be
easily overprovisioned.

But now we get to the squeeze.  Off the wireless POPs, I'm running radio
circuits and they are orders of magnitude less bandwidth than everything
I've described so far.  Overprovisioning also gets problematic -- there
are very few offsets.  And, as the adage goes, God only made so much
spectrum (there are a lot of good propagation reasons to stay in the
low-band VHF part of the spectrum where EMS has traditionally been --
but not a lot of capacity there).  
	Exactly how I arrange my priority service need not be visible to my
municipal ISP.  Let's assume I use some kind of diff-serv arrangement --
what's important is that the ISP not mangle the DSCP by routers enroute
to and from my enclaves attached to that ISP's net.  Diff-serv here is a
good example because it addresses per hop behaviors.  My ISP already
Does the Right Thing over his segment, so let's not pay tax money to
overkill that part -- I'm particularly interested in the radio-WAN per
hop behavior where certain traffic needs precedence over other.  
	For example, I may be running a video feed for situation awareness
(e.g. a web-cam mounted on the fire engine) and this data may be relayed
to the press.  I may be running medical telemetry from the EMTs to the
hospital as they work an injury.  And I may be running a scene-leader
<--> command center voice discussion.  These applications bear different
QoS needs TO MY LOCAL parts of the internet but not to my ISP because
he's more than met them through the overprov.  

On Tue, 2002-11-12 at 01:59, Ken Carlberg wrote:

> 
> we've talked about this a few weeks ago.  the IEPREP is a rather 
> different group than the others within the IETF in both the wide 
> variety of backgrounds participating, and those that will be reading
> the documents produced by it.  normally, I would agree that there is
> no need to make any extra strong statement that IETF documents are not
to 
> be confused as mandates that must be followed by the comunity or
vendors.
> however, I think its important to take into account non-technical
folks,
> and more importantly people unfamiliar with the IETF, and go the extra
> mile to point out things.  this also means being a bit more
descriptive
> than normal in drafts to make sure all technical participants
understand 
> whats being accomplished.
> 
In this respect, we probably ought to look farther than the
protocol-only IETF view.  The problems we're trying to tangle with have
to do with provisioning, policy, and practices as much as they do with
protocols.  We can't mean ANY of the Ao, security, QoS control or reach
to mobile platforms without attention to all.