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

From: "Gunn, Janet" <[email-masked]>
Date: Thu, 3 Jul 2003 10:09:19 -0400

Scott, Ran,

Thanks for your comments.  I think we understand your specifics and can
aggregate them into the following views:

1)	It would be better to develop the guidance as an informational RFC
versus an official BCP, and then maybe later, if its application and
experience warrants, advance it as a BCP.

I think we agree with this approach.  We certainly agree that our objective
to provide guidance to our providers does not have to be met with
"standards", but can be met with less "official" documents.  We just want to
gain as much as possible community review and consensus on how best to
implement an ETS.  The BCP description in the Charter sounded like the right
thing, but if an informational RFC is more appropriate, then that is ok.  

2)	If we are trying to develop a BCP, then the "suggested" work
initiatives should be removed and developed separately as IEPREP
requirements products for input to the protocol WGs.

We agree, and if the document is continued as a BCP initiative, we will edit
accordingly.  I also presume that if the document is an informational RFC,
then it may be more appropriate to discuss the work in progress and its
potential application, but that we should nonetheless initiate requirements
docs for the work in progress we want to support and / or refine.

3)	We should not try to bypass the normal review process for assignment
of values to variables.

We agree and that was not our intent.  Rather, we were trying to align with
the notion that a BCP should deal only with what can be done with existing
protocol standards, and not with protocol extensions.  Thus, we were
advocating use of consistent local practices in variable value assignments
as permitted in the standards until such assignments could be properly
reviewed and advanced as standard.  If we make the document an informational
RFC versus a BCP, are we on better ground to suggest such local practice
consistency in variable value assignment?  

We do not remember any document as you describe from Fred and if you could
give us a pointer to it, that would be much appreciated.  If he has not yet
released a draft, then we would endorse your encouragement of him to do so.

Finally, as a point of info, page 174 of the SIP RFC 3261 describes the
Priority header (which is separate from the Resource-Priority header that is
only in draft status and may have been what you were thinking of).

Thanks again for the comments.  I think the above summarizes the view, but
if we missed some point or got a point wrong, please let us know.  

-----Original Message-----
From: Scott Bradner [mailto:[email-masked]]
Sent: Wednesday, July 02, 2003 9:31 PM
To: Berg, Dennis; [email-masked]; [email-masked]
Cc: [email-masked]; Gunn, Janet; [email-masked]; Kaczmarek,
Richard NE
Subject: RE: [Ieprep] IP Bridging Configuration Guidance for IEPREP
Telep hony

> Would appreciate your specific feedback, specifically on our views of how
> 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

> 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.  

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

> 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.

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

> 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.

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

> 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.

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

> 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.

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 - 

> 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.

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

> 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.

see # 5

> 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.

see # 5

> 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. 

see #5

> 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.

see #5

> 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.

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

> 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. 

see #5

> 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.  

see #5

> 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.

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

---

From: Scott Bradner <[email-masked]>
Date: Thu, 3 Jul 2003 10:16:23 -0400 (EDT)

> give us a pointer to it, that would be much appreciated. 

draft-ietf-ieprep-packet-marking-policy-01.txt

but the ID has expired - you can find it through google

Scott

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

---

From: Ken Carlberg <[email-masked]>
Date: Thu, 03 Jul 2003 15:31:49 +0100

> but the ID has expired - you can find it through google

the draft can also be found in the proceedings of the Tokyo IETF, where 
Fred gave a presentation on the draft (see Transport area, IEPREP).  
http://www.ietf.org/proceedings/02jul/index.html

-ken