Re: [PEPPERMINT] Data model for "reachability data" and naming/terminology for group of addresses

"Jean-Francois Mule" <jf.mule@cablelabs.com> Tue, 08 July 2008 21:13 UTC

Return-Path: <peppermint-bounces@ietf.org>
X-Original-To: peppermint-archive@optimus.ietf.org
Delivered-To: ietfarch-peppermint-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB35F3A6AF4; Tue, 8 Jul 2008 14:13:59 -0700 (PDT)
X-Original-To: peppermint@core3.amsl.com
Delivered-To: peppermint@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33CBC3A6ABC for <peppermint@core3.amsl.com>; Tue, 8 Jul 2008 14:13:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.313
X-Spam-Level:
X-Spam-Status: No, score=-0.313 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQel4vftkS9y for <peppermint@core3.amsl.com>; Tue, 8 Jul 2008 14:13:58 -0700 (PDT)
Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 767FD3A6AF4 for <peppermint@ietf.org>; Tue, 8 Jul 2008 14:13:58 -0700 (PDT)
Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.2/8.14.2) with ESMTP id m68LE89I029081; Tue, 8 Jul 2008 15:14:08 -0600
Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Tue, 8 Jul 2008 15:14:08 -0700 (MST)
X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com)
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 08 Jul 2008 15:13:53 -0600
Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C6012900C4@srvxchg3.cablelabs.com>
In-Reply-To: <OF70AE4588.D4FC8E58-ON80257474.00506742-80257474.00516285@nominet.org.uk>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [PEPPERMINT] Data model for "reachability data" and naming/terminology for group of addresses
Thread-Index: AcjXm8RtuZYmIK/fS+aPfBbSQ+ncXAJojV7Q
References: <9AAEDF491EF7CA48AB587781B8F5D7C601216A72@srvxchg3.cablelabs.com> <OF70AE4588.D4FC8E58-ON80257474.00506742-80257474.00516285@nominet.org.uk>
From: Jean-Francois Mule <jf.mule@cablelabs.com>
To: Ray.Bellis@nominet.org.uk
X-Approved: ondar
Cc: peppermint@ietf.org
Subject: Re: [PEPPERMINT] Data model for "reachability data" and naming/terminology for group of addresses
X-BeenThere: peppermint@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection <peppermint.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/peppermint>, <mailto:peppermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/peppermint>
List-Post: <mailto:peppermint@ietf.org>
List-Help: <mailto:peppermint-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/peppermint>, <mailto:peppermint-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: peppermint-bounces@ietf.org
Errors-To: peppermint-bounces@ietf.org

Ray,

   Thank you for the comments and sorry for the delay in responding.
More inline.

Jean-Francois.

Ray wrote:
> Can you elaborate on what a "Service Area" / "Address Group"
> actually is?
It is basically a way to logically group user addresses that can be
   - reached via a given Signaling path Border Element (SBE),
   - reached via a domain from which SIP servers can be located (a la
rfc3263)
Folks often picture this by saying it is a group of users reachable via
a common (SIP) 'route'.

> In the UK for our Central Numbering Database we've developed a
> concept of
> a "Destination Group" - that being all those numbers (or
> destinations)
> which are supposed to be routed identically.  Is that the same
> thing?
I believe so.  Would folks prefer Destination Group then?


> Note however that this does not mean that every originating carrier
> has to
> route them to the same place as every other carrier.
> 
> For example if Carrier A (a terminating carrier) has:
> 
>   DG1 = (a, b)
>   DG2 = (c, d)
> 
> then originating Carrier B routes destinations in DG1 to a
> particular
> interconnect, and routes DG2 to some other interconnect.  However
> Carrier
> C might have completely different interconnects with Carrier A.
> 
> In the UK model the actual interconnect addresses are private
> information
> bilaterally agreed between carriers.
> 
> kind regards,
> 
> Ray

_______________________________________________
PEPPERMINT mailing list
PEPPERMINT@ietf.org
https://www.ietf.org/mailman/listinfo/peppermint