[Speermint] Location Function in SPEERMINT

["Stastny Richard" <[e-mail]>]

Hi all,
 
sorry, but I am only able to reply with a short statement, because I am
on vacation and have only limited time and bandwitdh (GPRS)

First, I consider this discussion regarding Infrastructure ENUM, LERG and LNP
important, but in the wrong WG. It should be discussed in ENUM. WG and
not in SPEERMINT
 
SPEERMINT is only dealing with Call Routing Data (CRD), which is defined
as the OUTPUT of ENUM or some other means.

This implies, that the location function (LF) defined in the
achitecture draft happens AFTER an ENUM query and therefore
cannot be the part of the LF.
 
The LF can only involve the location of the destination "network"
as defined in SPEERMINT by the use of CRD (which
is basically a SIP URI because we are currently talking only SIP
in SPEERMINT)
 
Of course SPEERMINT needs to define what it considers CRD,
and AoR or the ingress point of a network.

BUT then SPEERMINT needs also to define how the ingress
point of a "network" is LOCATED given a SIP AoR.
 
Richard
 

________________________________

Von: Tim Dwight [mailto:[e-mail]]
Gesendet: Do 25.05.2006 20:17
An: 'Michael Hammer (mhammer)'; [e-mail]; Stastny Richard; 'Brian Rosen'; 'Francois D. Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer'; [e-mail]
Betreff: RE: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF - SF



Michael Hammer said:

> Tim,
>
> The LERG and LNP databases are intrinsically tied to the operation of the
TDM
> infrastructure.  Any design that perpatuates these systems when their
reason
> for being (TDM) goes away is a faulty design.

OK with me.  I only meant to point out that right now I have these
capabilities, so recreating them isn't a high priority.


>
> DNS and ENUM provides the equivalent information and mechanisms to do what
is
> needed in the IP domain.  As such, a design that makes dependencies on
legacy
> systems is deficient.  I wouldn't support such a kludge.

Fine.

I'm a big fan of IP-domain solutions.  Specifically Infrastructure ENUM
looks really handy; my point before was that it's moreso when used in what
Richard called "option 1".  The alternative ("option 2") only replicates the
"kludge" to which I already have access.

And to be fair to Richard, he did point out (subtly) that the latter claim
is a bit myopic.  There are existing means by which VSPs can gain access to
number portability information relative to national destinations.  They
don't have such access, at least not easily and not universally, to number
portability information relative to international destinations.  If that
could be provided by Infrastructure ENUM (either "option 1" or "option 2")
it would be useful and would not simply replicate existing capabilities.

Bottom line, both options defined by Richard, would add value.  Option 1
adds more value but is specific to destinations identified by E.164 numbers
or URIs with imbedded E.164 numbers.  Which is the problem closest to hand.


>
> That said, if there are backward compatibilities during the transition,
where
> some information just happens to be known by external systems, such as you
suggest
> below, I don't see that as a problem.  I am just wary of ending up with
two
> systems in the end when one would do.

Isn't it inevitable that for some time, both will exist?  Just as the GSTN
and VoIP will coexist for some time, so will their supporting
infrastructure.

Don't get me wrong.  I'm not saying "because I have an SS7 -based solution
to LNP I don't need an IP -based solution".  All I'm saying is that when
given the option of using Infrastructure ENUM to recreate (and in the case
of international destinations, extend) the capability I already have, and
using it to do that and more, I'm inclined to prefer the latter. 


>
> Mike


> -----Original Message-----
> From: Tim Dwight [mailto:[e-mail]]
> Sent: Wednesday, May 24, 2006 6:19 PM
> To: 'Stastny Richard'; [e-mail];
> [e-mail]; Michael Hammer (mhammer); 'Brian Rosen';
> 'Francois D. Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer';
> [e-mail]
> Subject: RE: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF
> - SF
>
> Richard,
>
> Yes I know I was mixing data and mechanism-to-access-data. 
> Still I believe the major point to be correct.  In many parts of the
> world there are already mechanisms (associated with Local Number
> Portability) to determine ownership of an E.164 number, hence use of
> ENUM for this purpose alone, will be unnecessary.
>
> To be clear, I believe that providing access via Infrastructure ENUM
> to LNP information may be very helpful; but only if Infrastructure
> ENUM provides more than just this.
>  If an Infrastructure ENUM query can combine (a) determination of the
> entity providing service to the destination, (b) determination of the
> corresponding LRN, if one exists, and (c) mapping of the routable
> number (either the number originally indicated, or the LRN) to a Layer
> 5 "point of ingress" specified by the entity providing service to the
> destination;  then Infrastructure ENUM is quite a handy mechanism.  If
> all it does is (a) then I don't need it.
>
> But in the end this is neither here nor there.  I am not wedded to any
> specific technology, I just need workable solutions to real business
> problems.
>
> Tim
>
>
> -----Original Message-----
> From: Stastny Richard [mailto:[e-mail]]
> Sent: Wednesday, May 24, 2006 4:38 PM
> To: [e-mail]; [e-mail]; Michael
> Hammer (mhammer); Brian Rosen; Francois D. Menard; Khan, Sohel Q
> [CTO]; David Meyer; [e-mail]
> Subject: Re: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF
> - SF
>
> Tim,
> 
> thanx for your reply, you are raising some important issues.
> Since it is already midnight here, I will reply to it in detail
> tomorrow
> 
> I am also working on a more detailed analysis and a draft which will
> require even some more time.
> 
> Just a quick one:
> 
> >In some parts of the world the function provided by "option
> 2" usage of
> >Infrastructure ENUM could be achieved in other ways (e.g.,
> the LERG and
> >NPDB in North America) so in those cases Infrastructure ENUM
> might be a
> >superfluous concept;  but if that's the right technical
> answer so be it.
> 
> Yes and no ;-)
> You are mixing up here the Registry and the ENUM DNS.
> The Registry is the LERG and NPDB (or is derived from), the ENUM DNS
> is the equivalent on IP of the SCP in the PSTN where the date is
> downloaded to.
> 
> Richard
> 
>
> ________________________________
>
> Von: Tim Dwight [mailto:[e-mail]]
> Gesendet: Mi 24.05.2006 23:00
> An: Stastny Richard; [e-mail]; 'Michael Hammer
> (mhammer)'; 'Brian Rosen'; 'Francois D. Menard'; 'Khan, Sohel Q
> [CTO]'; 'David Meyer'; [e-mail]
> Betreff: RE: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF
> - SF
>
>
>
> Richard,
>
> Thank you for the clarification.  I understand the distinction you are
> making.
>
> My objective is to be able to translate a destination identifier
> (E.164 number of alphanumeric AoR) into the address of a Layer 5
> entity designated by the organization providing service to the called
> party.  With infrastructure/carrier ENUM I could do this (as described
> in your Option 1), but because ENUM is specific to E.164 numbers it
> would only work for E.164 -formatted destination identifiers.
>
> In pictures, your Option 2 seems to me to imply the following:
>
>                +----------------+                 +----------+
> E.164          | infrastructure |     serving     | identify
> |     network
> ingress
> destination -->| ENUM           |---> carrier --->| ingress 
> |---> point
> specified
> identifier     | (option 2)     |     identity    | point    |     by
> serving carrier
>                +----------------+        ^        +----------+
>                                          |
>                +----------------+        |
> non-E.164      | map domain in  |        |
> Destination -->| URI to carrier |--------+
> Identifier     | identity       |
>                +----------------+
>
> In some parts of the world the function provided by "option 2" usage
> of Infrastructure ENUM could be achieved in other ways (e.g., the LERG
> and NPDB in North America) so in those cases Infrastructure ENUM might
> be a superfluous concept; but if that's the right technical answer so
> be it.
>
> The "identify ingress point" function would need to be defined.  I
> would like it to consider the specified destination (in addition to
> the carrier providing service to that destination); and I would like
> the procedures to be such that the serving carrier controls (in a
> reasonably dynamic
> way) the point at which traffic destined to a particular destination,
> enters his network.  If those requirements can be met, I think this
> approach is workable.
>
> Its biggest drawback is that it precludes a solution ("option 1" usage
> of Infrastructure ENUM) that is sufficient for the majority of today's
> needs.
> It optimizes for a problem that will exist in the future at the
> expense of solving problems that exist today.  I realize that solving
> today's problems may not be SPEERMINT's focus, or (arguably) even
> within its charter, but I would hate to see recommendations from
> SPEERMINT preclude or significantly delay solving them.
>
> Suppose we did something like this:
>
>                +----------+     [pseudo     +----------------+
> non-E.164      | identify |     or real]    | infrastructure
> |     network
> ingress
> destination -->| "pseudo" |---> E.164   --->| ENUM          
> |---> point
> specified
> identifier     | E.164    |     number      | (option 1)     |     by
> serving carrier
>                +----------+                 +----------------+
>
> We could let the ENUM working group define Infrastructure ENUM as
> described in your Option 1 (which is as you know already commercially
> available from a few sources) and SPEERMINT could define the "identify
> pseudo E.164" function that in my diagram feeds into it.  This
> function might be as simple as mapping the domain part of the URI to
> an E.164 number uniquely associated with the network providing service
> to the specified destination.  Unless this is a lot harder than it
> seems, this shouldn't keep us busy too long :-)
>
>
> Tim
>
>
> -----Original Message-----
> From: Stastny Richard [mailto:[e-mail]]
> Sent: Wednesday, May 24, 2006 11:16 AM
> To: [e-mail]; Michael Hammer (mhammer);
> Brian Rosen; Francois D. Menard; Khan, Sohel Q [CTO]; David
> Meyer; [e-mail]
> Subject: Re: [Speermint] RE: SPEERMINT Peering Architecture -
> LF - OF - SF
>
> Tim,
>
> >> ... 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)
>
> >At the risk of asking an off-topic question (realizing that
> ENUM is not
> >within scope for SPEERMINT), can I ask where the idea that
> >Infrastructure ENUM queries return SPIDs, comes from?  It is
> my intent
> >to provide a point of interconnection to be used by the requesting
> >entity to hand to me a call to the specified number.  I do
> not intend
> >that the only meaningful part of the URI returned from the
> ENUM query,
> >be
> the domain name.
>
> thank you for raising this important point. I tried to raise
> this some time ago, but got no clear answer
>
> Currently there exist two lines of thought about the usage of
> Infrastructure (and also Carrier ENUM in private trees)
>
> 1. Put in ENUM the ingress point(s) e.g.
> sip:[e-mail] 2.
> Put in ENUM the AoR only: e.g. sip:[e-mail]
> (provider.net is what I meant with SPID)
>
> Most currently prefer option 1, especially in private ENUM trees.
>
> IMHO this is the wrong approach:
>
> There should be a clear separation (and it is in the charter)
> between ENUM and SPEERMINT SPEERMINT peering MUST be able to
> work standalone and without ENUM.
>
> Option 1 assumes also that the user is entering ALWAYS an
> E.164 number as identifier.
>
> But what if he is entering an AoR?
>
> SPEEMINT peering MUST be able to resolve this too so you need
> to find the ingress point independant of ENUM e.g. via RFC3263.
>
> If this MUST be possible, why not enter in (any) ENUM just
> the AoR, if you must be able to resolve the AoR anyway?
>
> Otherwise you need to manage two mappings separate 1. the
> E.164 to ingress point 2. the AoR mapping to ingress point
>
> this is not a good idea
>
> This is the reason why I would prefer to enter in ENUM AoRs
> only the user part in ENUM is always the E.164 number (for
> privacy reasons) the domain part is the SPID, which is mapped
> later to find the ingress point
>
> the calling user may then also use an alis AoR such as
> sip:[e-mail]
>
> regards
>
> Richard
>
>
>
> ________________________________
>
> Von: Tim Dwight [mailto:[e-mail]]
> Gesendet: Mi 24.05.2006 16:46
> An: Stastny Richard; 'Michael Hammer (mhammer)'; 'Brian
> Rosen'; 'Francois D.
> Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer'; [e-mail]
> Betreff: RE: [Speermint] RE: SPEERMINT Peering Architecture -
> LF - OF - SF
>
>
>
> Stastny, Richard said:
>
> > ... 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)
>
> At the risk of asking an off-topic question (realizing that
> ENUM is not within scope for SPEERMINT), can I ask where the
> idea that Infrastructure ENUM queries return SPIDs, comes
> from?  It is my intent to provide a point of interconnection
> to be used by the requesting entity to hand to me a call to
> the specified number.  I do not intend that the only
> meaningful part of the URI returned from the ENUM query, be
> the domain name.
>
> tim
>
>
>
>
> _______________________________________________
> Speermint mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/speermint
>
>
>
>
> _______________________________________________
> Speermint mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/speermint
>

_______________________________________________
Speermint mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/speermint




_______________________________________________
Speermint mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/speermint