RE: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt

["Medhavi Bhatia" <[e-mail]>]

Hi Otmar,

Thanks for comments. I have tried to provide some clarifications below.

-Medhavi.

> -----Original Message-----
> From: Otmar Lendl [mailto:[e-mail]]
> Sent: Friday, March 03, 2006 8:19 AM
> To: [e-mail]
> Subject: Re: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt
> 
> >
> > Network Working Group                                          M.
Bhatia
> > Internet-Draft                                    NexTone
Communications
> > Expires: August 30, 2006                               February 26,
2006
> >
> 
> This draft is quite helpful as it provides clarificatons concerning
the
> terminology and describes some setups.
> 
> Some questions, though:
> 
> > 2.  Terminology
> 
> >       Service Provider (SP): We use the term Service Provider in
this
> >       document to refer to a SIP Service Provider[3].  The
individual
> >       types of SPs are defined below.
> >
> >          Access SP: An SP which acts as the first hop between the
> >          subscriber and the Core SP.
> 
> Is this Access SP role restricted to the SIP layer or is it implied
> that this Access SP also is the layer 3 access provider for "O"?
> 

For purposes of this doc and given the WG scope, the Access SP (if one
exists in the flow) is a L5 (sip aware) SP. The case where there is a
layer 3 SP and is different from the Core SP or Access SP is probably
not worth considering since there is no SIP peering involved between the
Layer 3 SP and the access/core SPs (I also think that in most cases if
the access SP exists, it will exist because it owns the layer 3). Also I
realize that there may not be many access SPs (L5) today, but chances
are that today's Layer 3 SPs will attempt to become tomorrow's Access
SPs.


> > 4.  Routing Architectures
> >
> >    1.  Direct Peering:
> >
> >           Federation: A federation is typically a set of SPs which
are
> >           terminating calls to each other using some well known
> >           mechanisms for settlement, address location and some other
> >           common administrative policies.  In most cases the peering
SPs
> >           are connected to a trusted private network and trust all
calls
> >           terminating on them over this network.
> >
> >              Federations typically use ENUM as the registry database
> >              (owned by the federation or a trusted third party) to
> >              provide address location services and applications like
> >              number portability.  Other aspects of the routing
policy
> >              (as described in Section 5) are implemented using edge
> >              proxies or session border controllers (Section 4.1).
> 
> This use of "Federation" fits in very well with my definition
> of draft-lendl-speermint-federations-00. Good.
> 
> Federations can only use ENUM if routing is based on E.164 numbers.
> If we ever switch to direct URI dialing, then ENUM cannot be used
> within a federation.
> 
> Btw, draft-lendl-domain-policy-ddds-00 provides a solution for
> selecting the right federation for a call and thus enables SPs
> to be part of multiple federations.
> 
> >
> > 5.  Requirements for route policy and architecture for peering
> >
> >    2.  Addressing: Whether the address of record of the termination
is
> >        an E.164 address or a generic AOR (e.g [e-mail])
> 
> IMHO: We should not design a system which does assume that E.164
> numbers are available as routing information.
> 
I'd agree. I am thinking there will be a lot more discussion on how the
presence of E.164 changes the situation (maybe dips into some legacy
system). In practice the access SPs and core SPs may be providing SIP
based access to legacy PSTN. I assume those scenarios are also in scope.

Medhavi.

> /ol
> --
> < Otmar Lendl ([e-mail]) | nic.at Systems Engineer >
> 
> _______________________________________________
> Speermint mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/speermint
> 
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.375 / Virus Database: 268.1.1/272 - Release Date:
3/1/2006
> 

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