Subject: RE: [Ieprep] IP Bridging Configuration Guidance for IEPREP Telep hony

From: "Berg, Dennis" <[email-masked]>
Date: Wed, 2 Jul 2003 20:16:50 -0400

Ran, James,

In our ID, we have tried to separate "RECOMMENDED" practices from
"suggested" work items for the IEPREP WG.   As noted below, all the
"RECOMMENDED" practices (we believe) have been checked for feasibility with
existing protocols without protocol extensions, and can be applied via local
administration.  The "RECOMMENDED" practices do include specifics for such
local administration, but we understand this is consistent both with BCP
intent and with the needs of our ETS service providers.  We recognize that
use of local and experimental values limits the implementation to a single
domain; however, the scope of the ID is just a single domain, which is the
scope of our discussions with the service providers.
Where we have seen protocol gaps, we have "suggested" (the flag word versus
"RECOMMENDED" for actual BCP recommendations) IEPREP initiatives to address,
and probably should be more explicit in characterizing such initiatives as
efforts to develop Requirements that can then be used as input to the
appropriate protocol WG.  

On a more detailed level, our "RECOMMENDED" practices and why we consider
them within scope are noted below:

1.  ETS call signaling should use the basic signaling protocol stack assumed
for the reference topology (Conventional SS7 [SS7] from AT to STP to SG and
SS7 over IP using M2UA [M2UA] over SCTP [SCTP] between the SG and MGC.) 
*  This recommends the use of specific existing protocols for carrying SS7
over IP, and so clearly meets the BCP scope of specifying what can be done
with existing protocols.

2.  There should be direct mapping of the CSN (international and / or
national) ETS call marking(s) and associated SS7 congestion priorities.
*  Recommends that two specific parameters of interest to ETS should be
mapped ("preserved" probably would have been a better choice of words) at a
signaling gateway. I.e., the SG should function just like an STP and send
out only what it receives without modifying the input.

3.  For an ETS call the same mapping and translation should be applied to
the call setup IAM being sent from the IP network to the CSN upon egress as
was applied to the IAM sent from the CSN to the IP network upon ingress,
e.g., in the U.S.A. the NSEP codepoint in the Calling Party Category (CPC)
and, if present, the optional Precedence parameter.
*  Recommends that the mapping and translation function - as specified for
the ETS parameters of interest in (2) - at ingress and egress to the
signaling gateway be symmetrical, i.e., that the network should be
transparent.

4.  The MPT3 congestion priority of the received IAM be propagated unchanged
in the outgoing IAM, (e.g., in the U.S., IAMs with NSEP set have a
congestion priority of one whereas all other IAMs have a lower congestion
priority of zero).
*  Specifically, recommends that the congestion priority of the IAM at
ingress not be changed at egress.

5.  Assign two values from the experimental and local use pool of Diffserv
codepoints to designate and differentiate International ETS and National
ETS. 
*  Our understanding is that the use of experimental and locally
administrable items within a single domain is a practice, not a protocol
extension.

6.  Correlate the two Diffserv codepoints with a PHB constructed by
"copying" the EF PHB, but perhaps changing some parameter values.
*  Our understanding is that defining a PHB for a Diffserv local and
experimental codepoint is matter of practice.

7.  Use the following specific experimental and local pool Diffserv
codepoints: assignments: National Emergency = 011111, International
Emergency = 011011
*  This recommendation just calls out specific values for convenience in
order to coordinate usage of the Diffserv values from this pool.

8.  Separate ETS traffic treatment, both signaling and data, from other
traffic treatment by the use of a dedicated MPLS Diff-serv codepoint in
E-LSPs
*  We understand that MPLS codepoints and E-LSPs are matters of local
administration.  We intend to clarify this recommendation to specify that
one of the two unused MPLS Diffserv codepoints should be used (specifically
6, since we understand that common practice is to use 7 for network
management).  Based upon the current practice of using 7 for network
management, we conclude that we are able to recommend the practice of using
6 for ETS within a single administrative domain. 

9.  Associate the Diffserv PHB with the MPLS Diffserv codepoint as is used
for Diffserv in general.
*  Again, if we can define the MPLS Diffserv codepoint at a matter of
practice, it would seem that we can also define its PBH as a matter of
practice.

10.  ETS calls should be specified by use of the SIP Priority header with a
designation of "emergency".  
*  We are not recommending changing the use of this field for notifying the
user.  We're just saying, for ETS calls, use it for its intended purpose.

11.  Use SDP attribute parameters to specify ETS sessions as either National
Emergency sessions using the attribute parameter value "x-NatETS" (where the
leading "x" is understood to be customary to designate non-standard values)
or International Emergency sessions using the attribute parameter value
"x-IntETS". 
*  Since we are recommending locally administrable values, we understand
this to be a matter of practice for a single administrable domain, rather
than protocol extension. 

12.  Use the MEGACO ContextRequest parameter for "emergency" (Boolean) to
indicate "emergency" and the MEGACO ContextRequest parameter for "priority"
with priorities 0-4.  
*  Our understanding here is that these parameters are already defined and
their use is a matter of local practice.  

Note that we do not include the SIP RPH in any of our recommendations.  We
recognize that the SIP section is there for information and that the ETS
namespace position needs to be officially pursued as a separate effort.

We are at the stage of discussions with vendors and carriers that requires
real (and preferably official) guidance on how we would like them to address
our ETS needs in their new IP deployments.  We understand a BCP carries with
it the endorsement of the IETF, and although it is not a standard, it has a
lot more weight than other non-standard RFCs.  We recognize that some could
raise the question of whether or not the IETF should advocate a practice
without a firm experiential base for knowing if it is the best (or even a
good) practice.  Our view, at least at the moment, is that an expert view of
what seems to be a "best practice in the absence of experience" is still a
lot better in meeting our needs than no view at all.

Would appreciate your specific feedback, specifically on our views of how
the ID's recommendations are in scope for a BCP.

Dennis, Janet, Pat, Kacz

-----Original Message-----
From: James M. Polk [mailto:[email-masked]] 
Sent: Wednesday, July 02, 2003 3:29 PM
To: Berg, Dennis; 'RJ Atkinson'
Cc: [email-masked]'; 'Janet Gunn'
Subject: RE: [Ieprep] IP Bridging Configuration Guidance for IEPREP Teleph
ony

At 12:23 PM 7/2/2003 -0400, Berg, Dennis wrote:

>Ran,
>
>Understand you comment, and we recognize that there is one case in the ID 
>where we are not using existing protocols, viz., the Resource Priority
Header.

Dennis - I believe you might have this backwards (maybe). The R-P header 
has had a requirements ID generated (and RFCd) by IEPREP (3487), and it is 
now properly being worked on by its existing Protocol WG (SIP). I don't see 
the same efforts (requirements IDs) for the other protocols mentioned 
within your ID (SDP, Diffserv, MPLS, MEGACO, etc) that (I believe) must go 
through the same process as the R-P header did (as painful as that was/is - 
hopefully R-P blazed a trail that others will find easier....).

>  But, we looked at the ieprep charter statements and thought they 
> supported that approach, at least partially:
>
>         The working group will develop a BCP RFC or set of RFCs, regarding
>         operational implementation of services for Emergency Preparedness 
> using
>         existing Internet protocols. The RFC may include identification 
> of gaps
>         in existing protocols and requirements for use in new protocol or
>         protocol feature design. It is out of scope for this working 
> group to
>         do protocol or protocol feature development.
>
>         Deliverables
>
>         Best Current Practice:
>          IETF Recommendations for the Emergency Telecommunications Service
>          using existing protocols

I believe this includes all existing extensions to existing protocols - 
which might be part of a discrepancy with your ID, because yours calls for 
many new extensions that each protocol's WGs haven't properly discussed 
(nor have many of these been discussed in IEPREP - SDP being the best 
example of one that hasn't been mentioned before).

I'd say that the R-P header is 'the one' mentioned within your ID that 
*has* been discussed within its appropriate WG, and SIP is close to working 
out the final details of it now. None of the other extensions called for in 
this new ID have been discussed on any other mailing list or in the WG 
meetings that I know of in the last 4 years.

>  - what can be done with existing protocols
>          and what can not be done.

What this ID calls for should be the results of much discussion and one or 
more requirements IDs calling for these extensions to occur with proper 
justification of usage and perhaps why existing mechanisms in each protocol 
can't solve what you want.

>I.e., the reference to the RPH is covered, at least in part, by the gap 
>analysis "what can not be done" component of the charter.  To the extent 
>that it is not, it seems that the right approach is to assume that the RPH 
>ID will be acted upon and become an RFC before the ieprep BCP is 
>finalized.  If this doesn't happen, of course we would have to revise the 
>BCP draft.

As an example of what I mentioned above, where exists a similar 
requirements ID and Standards Track mechanism ID for what you want in/for 
SDP? Or Diffserv (? Or MEGACO?

I believe each doc is required per protocol, per mechanism (meaning there 
could be multiple docs written within one or each WG to solve what you/we 
need).

>Dennis Berg
>CSC
>[email-masked]
>
>-----Original Message-----
>From: RJ Atkinson 
>[<mailto:[email-masked]>mailto:[email-masked]]
>Sent: Wednesday, July 02, 2003 10:25 AM
>To: Janet Gunn
>Cc: [email-masked]
>Subject: Re: [Ieprep] IP Bridging Configuration Guidance for IEPREP
Telephony
>
>On Wednesday, Jul 2, 2003, at 06:21 America/Montreal, Janet Gunn wrote:
> > Several of us have coauthored a Best Common Practices ID on
> > configuring a single domain, IP bridging, topology to support
> > Emergency Telecommunications Service.
>
>Thanks for the heads-up. :-)
>
>A BCP document ought to represent actual currently deployed practice and
>what the community believes to be the best practice at the time the
>document
>is published.
>
>Readers probably should consider whether those two properties hold
>for the contents of the above document when reviewing the document.
>
>Ran
>
>_______________________________________________
>Ieprep mailing list
>[email-masked]
><https://www1.ietf.org/mailman/listinfo/ieprep>https://www1.ietf.org/mailma
n/listinfo/ieprep 

cheers,
James

                                *******************
                    The answer is "42", what's the question?

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 2 Jul 2003 21:24:55 -0400

On Wednesday, Jul 2, 2003, at 20:16 America/Montreal, Berg, Dennis 
wrote:
> our ETS needs in their new IP deployments.  We understand a BCP carries
> with it the endorsement of the IETF, and although it is not a standard,
> it has a lot more weight than other non-standard RFCs. 

There is substantial experimental data (e.g. Navy TAC-4 workstation
contract) that the US Government is not restricted to citing 
standards-track
documents in its procurements, contracts, or agreements.  Instead,
the evidence indicates that any open specification is something that
could be used in a procurement, contract, or agreement.  So the state
of DISA or NCS (or any other party's) negotiations with vendors, 
operators,
or others is quite irrelevant to any IETF Working Group.

An alternative approach would be for a set of concerned individuals or
an organisation (e.g. DISA or NCS) to publish an Informational RFC as
a position document, then work with operators to obtain appropriate
practical deployment experience, then AFTERWARDS work towards moving
a (possibly modified based on experience) document forward for 
consideration
as BCP.  This would be a more productive approach in my own view.

I continue to be concerned that contractors of the US Government are
not acting as individuals here, but rather acting based primarily on
who is paying which salaries.  And I also continue to be concerned that
those persons are not giving due and fair consideration of the 
International
(i.e. non-US) nature of both the IETF and the global Internet.

> We recognize that some could raise the question of whether or not the 
> IETF
> should advocate a practice without a firm experiential base for knowing
> if it is the best (or even a good) practice. 

Not "some could" ask those questions, but rather that each active 
participant
in this WG NEEDS to consider those questions *as a normal part of being
an active participant in an IETF WG*.  Of course different individuals 
might
reach different conclusions -- on any question before any IETF WG -- but
the responsibility of the IETF participant is to carefully consider 
exactly
those sorts of questions.

As near as I can tell, it would not be consistent with past IETF 
decisions
and policies for IETF to publish a BCP about a practice that has 
negligible
deployment experience -- particularly in the situation at hand where 
there
are significant unresolved technical concerns with the specific 
proposal.

> Our view, at least at the moment, is that an expert view of what seems
> to be a "best practice in the absence of experience" is still a lot 
> better
> in meeting our needs than no view at all.

The working definition of "expert" is very much in the eye of the 
beholder
in this WG.  There is significant evidence of non-consensus on the 
problem
definition as well as on the "expert's view" of how to proceed.  While
that is sad, it is also reality.  We ought to keep grounded in reality.

Yours,

Ran

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

---

From: Scott Bradner <[email-masked]>
Date: Wed, 2 Jul 2003 21:31:03 -0400 (EDT)

> the ID's recommendations are in scope for a BCP.

if the doc is designed to ask other IETF working groups to explore
how to meet requirements that teh IEPREP WG feels need to be
met to support emergency traffic then it can not be a BCP by definition
and I agree with James that the odc should be split unto individual 
documents that provide ieprep requirements on a per technology nasis

if the doc is intended to tell ISPs and enterprises what the IEPREP
thinks is the best way to meet the needs of emergency traffic it must
be based on technology that the ISPs or enterprises have or can get
thus, if the doc suggests changes or additions to other IETF 
technologies (including having a SIP recource header) then it
can not be published as a BCP until those changes have been accepted,
and woudl have to be revised based on what the other IETF WGs actually do

to your specific points

> efforts to develop Requirements that can then be used as input to the

I think a BCP should just say what is recommended to meet the needs
and think teh difference between RECOMMENDED and "suggested" is too 
fine a difference to be clear to the reader

> over IP, and so clearly meets the BCP scope of specifying what can be done

if indeed it points to existing RFCs saying how to transport the 
particular SS7 functions over SCTP then this is in scope 

> out only what it receives without modifying the input.

I may be confused but if its just SS7 stuff I'm not sure the IETF is 
right place to make recommendations

> signaling gateway be symmetrical, i.e., that the network should be

if this is a recommendation on how a SIP field should be used then 
it should be done by the SIP WG - ieprep could tell sipping that 
there is a need to transport the  NSEP codepoint to the gateway
and the SIP wg can think about the best way to do that

> ingress not be changed at egress.

I do not know how this actually applies to transporting things
over IP networks - if it saying that data needs to be carried from the
gateway to the IP end node then the comment for #3 applies - 

> administrable items within a single domain is a practice, not a protocol

I do not think that we can reasonabally avoid the normal review process
for this type of thing by saying its just a local matter - this is defining
a specific use of a value and any such definition should go thorugh
the normal process for that variable - anything else distorts the 
review process that has been properly established for the variables

> experimental codepoint is matter of practice.

see # 5

> order to coordinate usage of the Diffserv values from this pool.

see # 5

> 6 for ETS within a single administrative domain. 

see #5

> practice, it would seem that we can also define its PBH as a matter of

see #5

> user.  We're just saying, for ETS calls, use it for its intended purpose.

I do not think there is a "SIP Priority header" yet approved

> this to be a matter of practice for a single administrable domain, rather

see #5

> their use is a matter of local practice.  

see #5

> lot better in meeting our needs than no view at all.

but that does not qualify a RFC to be designated a BCP - it could 
be designated experimental but without any indication that
things would actually do what is needed it clearly can not be a BCP

and again, I agree with James that the right way forward for these
recommendations is to agree on documents that have the requirements 
for the other WGs and send them off to those WGs

the idea behind the BCP deliverable in the charter came from the
1st BOF where it was pointed out that there were some things
that were actually being done in today's networks and it was
pointed out that it woudl be useful to write them down - Fred Baker
did a pass on this and I've suggested to him that he revive that 
ID for further consideration now that the other work is mostly
done

Scott