[Speermint] RE: SPEERMINT Peering Architecture - LF - OF - SF

"Stastny Richard" <Richard.Stastny@oefeg.at> Wed, 24 May 2006 08:33 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fionw-0002Q8-E2; Wed, 24 May 2006 04:33:20 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fionv-0002P6-9K for speermint@ietf.org; Wed, 24 May 2006 04:33:19 -0400
Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fiont-0001yE-O3 for speermint@ietf.org; Wed, 24 May 2006 04:33:19 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 24 May 2006 10:37:23 +0200
Message-ID: <32755D354E6B65498C3BD9FD496C7D463C4FD7@oefeg-s04.oefeg.loc>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: SPEERMINT Peering Architecture - LF - OF - SF
Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMAAAWSswAAMILuAAATumxgAG4BNwABEZoVA=
From: Stastny Richard <Richard.Stastny@oefeg.at>
To: "Michael Hammer (mhammer)" <mhammer@cisco.com>, Brian Rosen <br@brianrosen.net>, "Francois D. Menard" <fmenard@xittelecom.com>, "Khan, Sohel Q [CTO]" <Sohel.Q.Khan@sprint.com>, David Meyer <dmm@1-4-5.net>, speermint@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243
Cc:
Subject: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF - SF
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=subscribe>
Errors-To: speermint-bounces@ietf.org

Michael,
> 
> Let me turn this around to you.

Good policy, answering a questing with another question ;-)
> 
> How much policy data do you stuff into ENUM?

None, the basic idea of Infrastructure ENUM (which
will be used for service providers is to provide
a domain name in a SIP URI = a service provider ID (SPID)

> 
> How general a database do you expect DNS to become?

Good question. The DNS is reliable, scalable and fast
and it is available. So IMHO if some information
is needed in some kind of database, DNS is the first
choice (public and/or private DNS)

> 
> Do you expect that all peers will be pointed to the same entry point
> into the network?

I assume with network you mean the destination "network"?
The answer is no,
 
> The thought was that before you blast the SF with INVITEs, it might be
> useful to learn something about the nature of the interface
> expectations.  

Agreed,

I would suggest to rename OF to PF (Policy detection Function)
IMHO the short description is ok
Operation Function (OF):  Purpose is to enable discovery and
> >       exchange of policy and parameters to be used in with the SF
> >       peering point.

the long description mentioning CALEA and Accounting
is a bit misleading an needs rewording. Especially
the negotiation of application servers is a bit
early at this time.


>For the most part these are bins into which things can be
> organized while this group gets started.  If later it is concluded a
bin
> isn't needed, then it can be removed and whatever was collected
handled
> by some other bin.

Ok

Richard
> 
> Mike
> 
> 
> > -----Original Message-----
> > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]
> > Sent: Tuesday, May 23, 2006 5:09 PM
> > To: Michael Hammer (mhammer); Brian Rosen; Francois D.
> > Menard; Khan, Sohel Q [CTO]; David Meyer; speermint@ietf.org
> > Subject: SPEERMINT Peering Architecture - LF - OF - SF
> >
> > Folks,
> >
> > One general statement in advance:
> > Coming from the VON Europe last week with discussions about
> > walled garden and IMS, my overall expression is that this
> > draft in IMS in text-mode.
> >
> > I have another question for clarification to this draft,
> > because I am confused:
> >
> > I do not understand that the LF is discovering the OF
> >
> >    o  Location Function (LF):  Purpose is to enable discovery
> > of the OF
> >       peering point.
> >
> >    o  Operation Function (OF):  Purpose is to enable discovery and
> >       exchange of policy and parameters to be used in with the SF
> >       peering point.
> >
> >    o  Signaling Function (SF):  Purpose is to enable the discovery
of
> >       endpoints and assist in discovery and exchange of
> > parameters to be
> >       used with the MF peering point.
> >
> > I always had the naive idea (also triggered by the SPEERMINT
> > chartert that e.g. ENUM is a LF and discovering the SIP URIs
> > uses in the SF
> >
> > How is now OF coming in between thsi, especially what is
> > listed in the draft, especially CALEA, Accounting and Applications?
> >
> > "Operational data mediation:  TBD
> >
> >    o  CALEA implementation:  TBD
> >
> >    o  Accounting:  Call Detail Record's (CDR's) MAY be
> > collected to be
> >       utilized by the peering operators.  Based on the
> > application, the
> >       format should be an open standard for common consumption of
> >       billing systems.  Operators may use this data for a number of
> >       reasons, including billing in the event the peering
> > relationship
> >       becomes asymmetric (unbalanced traffic flow) or there
> > is a Tier 1
> >       to Tier 2 relationship.  In order to limit the potential for
> >       billing systems to impact the OF, a separate server should be
> >       created to maintain all records collected from a single
> >       interconnection to any number of OF's.
> >     An OF can also be a special function that contains bi-laterally
> >    disclosed information about the application servers and
> > databases of
> >    each IP service provider. An example of this function is
> > to allow a
> >    session to select a better suited application server from a set
of
> >    application servers located inside both service providers'
> > network.  "
> >
> > Richard
> >

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint