RE: [Speermint] Location Function in SPEERMINT

["Reinaldo Penno" <[e-mail]>]

> -----Original Message-----
> From: Stastny Richard [mailto:[e-mail]]
> Sent: Thursday, May 25, 2006 1:26 PM
> To: [e-mail]; Michael Hammer (mhammer);
> [e-mail]; Brian Rosen; Francois D. Menard; Khan,
Sohel Q
> [CTO]; David Meyer; [e-mail]
> Subject: [Speermint] Location Function in SPEERMINT
> 
> 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.
[[Reinaldo]] 

That's maybe one of the most important issues. This could be complicated
by the geographically dispersed networks with several entry points.
Although this might be an interesting problem it might be a rathole.


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

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