Subject: [Ieprep] IEPREP Vienna meeting minutes

From: "King, Kimberly S." <[email-masked]>
Date: Tue, 29 Jul 2003 09:10:41 -0400

Carlberg presentation

Basic telephony and general requirements were acceptable (i.e., no
objections) to the working group.  The framework will undergo another pass
through.
Polk - raised the issue that the IETF use terms in alignment with the ITU.
The ITU uses the initialism TDR (telecommunications for disaster relief) vs.
ETS.  

Carlberg stub domain presentation

Berg - wants to know if access links and transit are part of some IEPREP
document, Scott says within a domain but not in plan to go beyond single
domain.  Desire has been expressed but not enough meet in traction to go
further. Scott feels the intention is both stub domains and transit over a
single domain.
Polk - wants to know EF relationship and things like MPLS ideas.

Gunn presentation

Polk - This document proposes extensions to a lot of existing protocols, and
a BCP is intended to use existing technology in its practices. The ideas in
this document might be better served if the ideas were broken up, replaced
by requirements, and moved into the appropriate working groups for
consideration. If the resulting mechanisms are standardized, then the
document can be revived in IEPREP for consideration. Further, the point is
that this document only proposed solutions, which are not appropriate. In
order for this document to have any use it must be made up of requirements.

Bradner - This document, as is, has no path forward. The use of experimental
codepoints makes it such that it won't be made into an RFC. Also, a best
common practices document must be possible with existing technology, and due
to the fact that you are using experimental codepoints, you don't meet that
requirement. If the media gateway is smart enough to differentiate between
ETS and non-ETS traffic, then the IP portion is not relevant, as two tunnels
can be created (1 - ETS; 1 - non ETS), and manage the priority in that way.

Henry (MCI) - There are no IP phones in the architecture, and therefore the
model is bad. Also, it doesn't consider cable networks at all.
Scott Bradner said that it was "a scenario that needs to be addressed, but
not the only one."

Dick Knight - asked a clarification on the requirement in the proposed BCP
for the use of M2UA rather M3UA. Dick stated that M2UA emulates SS7 MTP2
level (Signaling Transport - Link Level) so that an existing SS7 MTP3
(Signaling Transport - Network Level) can be used without it knowing that it
is operating in an IP packet environment. Similarly, M3UA emulates the
Signaling Network Level of SS7, so that ISUP and other Application Parts of
the SS7 stack, can be used without knowledge of the underlying IP network.
Janet's presentation explicitly stated that M2UA MUST be used in order to
preserve SS7 ISUP parameters. Dick pointed out that whether M2UA or M3UA is
used, the ISUP parameters are unaffected. He asked for an explanation of
this requirement.

Dick Knight also said  "People are using M3UA or M2PA. Nobody is using
M2UA."  Also "There is no point in using the (current) SIP emergency header
if you are going to a CSN phone. The SIP emergency notification will never
get there. The SIP emergency notification only makes sense if it is going to
a SIP phone."

Bradner presentation

Scott went over general concepts of multi-homing user sites and avoiding
single points of failure in general.  These types of techniques lead to
resilient networks.  He then asked the working group if they thought IEPREP
needed to do anything in writing documents to help network operators build
such networks.  The working group pointed out that ISPs tend to provide
these capabilities in order to support their customers.  Nothing in their
provisioning was particularly relevant to physical emergencies as IP
networks already route around failures and handle problems with
infrastructure (e.g., backhoe fiber cuts) on a daily basis without customer
impact.  The conclusion of the discussion was that IEPREP did not have any
additional role in defining documents for High Availability Networks.

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

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 29 Jul 2003 09:53:35 -0400

On Tuesday, Jul 29, 2003, at 09:10 America/Montreal, King, Kimberly S. 
> further. Scott feels the intention is both stub domains and transit 

I'm unable to parse/lex:
	"Desire has been expressed but not enough meet in traction
	to go further."

Which desire was expressed ?
What does "not enough meet in traction" mean ?

Ran