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

From: "Livingood, Jason" <[email-masked]>
Date: Thu, 2 Mar 2006 13:33:39 -0500

FYI for the WG on this draft.  This is on the tentative agenda at the
Dallas meeting (should be finalized shortly).
 
Jason

________________________________

From: Medhavi Bhatia [mailto:[email-masked]] 
Sent: Sunday, February 26, 2006 12:44 AM
To: [email-masked]
Cc: [email-masked]; Livingood, Jason
Subject: I-D draft-bhatia-sip-peering-00.txt

Abstract

   The purpose of this document is to help the IETF community understand

   the route architectures being used today in SIP based peering

   environments and to outline a set of requirements based on the same

   for discussion within the community.

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

---

From: Otmar Lendl <[email-masked]>
Date: Fri, 3 Mar 2006 14:18:45 +0100

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

> 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 [email-masked])

IMHO: We should not design a system which does assume that E.164
numbers are available as routing information.

/ol
-- 
< Otmar Lendl ([email-masked]) | nic.at Systems Engineer >