Subject: [drinks] SPPF changes proposal

From: Mickael Marrache <[email-masked]>
Date: Fri, 2 Mar 2012 12:38:16 +0200

Hi DRINKS,

Following the conversation we had today, I would like to speak about the
issue raised by David concerning the data model.

Please, let's take a look at the figure present in the joined SPPF-user
ENUM.jpg file.

To meet the requirements deduced from the user ENUM use case, a direct
association between the TN and route record types has been added. In this
case, we have each TN associated to a route record directly. But, since
peering is defined at the route group level, there is no easy possibility
to share these direct associations. So, one solution is to include these
route records in a dummy (since the included route records have not common
routes) destination group DG-1. Then, we also create a dummy (since it
doesn't contain any route) route group RG-1 and associate it to DG-1. Then,
the route group may be offered to a peering organization.

The aforementioned solution disturbs me in two points. First, since the
destination group DG-1 and the route group RG-1 are not used for their
primary reason (a destination group allows grouping of public identifiers
that share a common set of routes, and a route group is generally used to
group route records that may correspond to a same "destination" - that's
why we share them as a block), it reveals a potential design issue. That's
what I have qualified them as dummy before. That's the first impression I
had when I heard this solution. The second point I want to raise concerns
the complexity added by this solution. In this case, when an originating
SSP wants to know the routes records associated to TN 1 for example, we
directly see that there is a route record associated to it (RR 1). But, we
don't know if this route record is accessible by the originating SSP. So,
we need to get the enclosing destination group DG-1 and then the route
group RG-1. We then check in its list of peering organizations if the
originating SSP exists. Then, the route record RR 1 (obtained from the
telephone number) is returned if the SSP is authorized. You will note that
this processing is not the regular one described by SPPF. In general, we
get the destination group associated to the queried public identifier, then
the route group, and then the associated route records if authorized. Why
do we need to use a different processing for the same kind of problem?
After all, we just want to get the route records associated to the
telephone number TN-1 in a user ENUM scenario (it's a banal scenario among
many of them), as we want to get the route records associated to another
public identifier in a regular scenario. That's what we have here: two
symptoms that reveal a design issue.

Now, let's take a look at the UML class diagram present in the joined
ProposedModel-SPPF.jpg file.

By using the abstraction defined by the abstract types PubIdentElement and
RouteElement, it allows defining a many to many relationship between public
identifier elements (i.e. single PI or destination group) and route
elements (i.e. single route record or route group). This relationship is
represented by the class-association RoutingAssoc. This association links
zero or more public identifier elements to zero or more route elements.
Also, to solve the scalability issue raised by Ken in the case one
registrant organization has to offer a huge number of associations
(previously route groups), we may use the same grouping concept for routing
associations, represented by the AssocGroup type. Thus, we define a
ShareableElement type that represents the basic entity that may be shared
by a registrant organization.

This model gives the possibility to define 4 combinations of associations:

   - Public identifier - Route record (solving user ENUM issue plus the
   possibility to link a single RN/TNP/TNR to a route record)
   - Public identifier - Route group (same as previous but with more than
   one route record)
   - Destination group - Route record
   - Destination group - Route group (regular scenario)

I don't think it's a big amount of change. The point here is to introduce
an abstraction, and to use an intermediary type between the public
identifier element and the route element. This intermediary type should be
used for peering. After all, the valuable information that is shared is an
association between public identifiers and routes, thus using a dedicated
type for this association should be the solution.

Also, I still think the peering aspect of this protocol should be defined
in a separated protocol that would support much more use cases than a
simple offer/accept model. I think we should have two standards, each one
focusing on a specific aspect of the problem, so we can decouple the two
problems. Then, the users would have the choice to use the routing
provisioning protocol or the peering protocol or both.

Maybe I'm missing something here, so if you see any issue (e.g. concerning
scalability) caused by this data model, please let me know. I would be
happy to hear your comments on these propositions.

Thanks

Mickael

---

From: "Cartwright, Ken" <[email-masked]>
Date: Fri, 2 Mar 2012 10:31:41 -0500

Hi Mickael,

There are misunderstandings about the data model and about the resolution process.

"To meet the requirements deduced from the user ENUM use case, a direct association between the TN and route record types has been added"
KJC:  Nothing has been "added", the data model has been this way for at least two years now.

"So, one solution is to include these route records in a dummy (since the included route records have not common routes) destination group DG-1. Then, we also create a dummy (since it doesn't contain any route) route group RG-1 and associate it to DG-1. Then, the route group may be offered to a peering organization."

KJC: The Destination Group and the Route Group you refer to as "Dummys", are not "Dummys" they are an integral and expected part of the data structure.

"First, since the destination group DG-1 and the route group RG-1 are not used for their primary reason (a destination group allows grouping of public identifiers that share a common set of routes, and a route group is generally used to group route records that may correspond to a same "destination" - that's why we share them as a block), it reveals a potential design issue."

KJC:  The Route Group you refer to as "not contain any route rec" is not accurate.  It may or may not contain Route Recs.  It is up to the registrant and registrar to decide whether they wish to have route recs on a given route group, regardless of whether they have also decided to have Route Recs directly associated with a PI (i.e. in the user ENUM case, where some PIs will/may have Route Recs that contain info that is specific to that PI).  The model allows both, depending on the Registrar's Registrant's need.

KJC:  The Destination Group and Route Groups involved here _do_ in fact serve the purpose that they are designed to serve.  They allow the peering visibility of large numbers of public identities and their routing information to be controlled at an aggregate with just a few number of API calls, as apposed to millions (one per PI or Route Rec).  They allow the Destination Group to be associated or disassociated to from one or more Route Group objects in a single command as the need arises, they allow the Route Group to be offered/accepted in a single command, rather than one per route rec (which there would be millions of in the User ENUM case) or one per PI.  They Route Group allows further control of the visibility based on source-based routing, and other routing selection algorithms that, at this time, would be vendor specific since they are not in the protocol (e.g. time-of-day, cost, etc).

"In this case, when an originating SSP wants to know the routes records associated to TN 1 for example...."

KJC:  The second paragraph in your note attempts to describe part of the resolution process, I've included the first part of your statement above.  It basically says that the resolution process is somehow different if Route Recs are directly associated with the PI than if they are associated with the Route Group.  This is not accurate.  First off, SPPP does not attempt to define how resolution servers must evaluate the data that SPP provisions.  Doing so would be folly, since TN resolution logic is much too involved, and often situation specific, including looking at data sources that do not even come in over SPPP (e.g. portability data, etc, etc).  However, the basic logic involves (1) using the lookup key (e.g. a TN) and the source of the query to get the Destination Groups that contain that lookup key that are visible to that source based on the Route Groups that that source has accepted (or auto-accepted), (2) collecting the Route Recs that are on the Route Group(s) if any and/or the PI if any, (3) evaluating the Route Recs based on their priority (and other vendor specific resolution logic, which the protocol does not attempt to specify), then sending the collected Route Recs out in the resolution response.  Notice that there are not two different flows.

KJC:  But from a bigger picture perspective, when the proposal was brought up yesterday, it was brought up under the guise that "the current data model is broken and it a hack in this area, so we need to do X, Y and Z".  This is simply not accurate, as I've described above.  Secondly, the proposed alternative simply does not work in terms of scalability for the User ENUM use case.  The proposal would result in millions of Route Recs (since in the user enum case the Route Recs contain PI specific data) having to be offered and accepted.  So even the primary target use case of the proposal just does not work well.  So given that the current model is not "broken" and is not a "hack" and given that the new proposal does not scale for the user enum use case, why add in the additional complexity that results from the new proposal?

Ken

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mickael Marrache
Sent: Friday, March 02, 2012 5:38 AM
To: [email-masked]
Subject: [drinks] SPPF changes proposal

Hi DRINKS,

Following the conversation we had today, I would like to speak about the issue raised by David concerning the data model.

Please, let's take a look at the figure present in the joined SPPF-user ENUM.jpg file.

To meet the requirements deduced from the user ENUM use case, a direct association between the TN and route record types has been added. In this case, we have each TN associated to a route record directly. But, since peering is defined at the route group level, there is no easy possibility to share these direct associations. So, one solution is to include these route records in a dummy (since the included route records have not common routes) destination group DG-1. Then, we also create a dummy (since it doesn't contain any route) route group RG-1 and associate it to DG-1. Then, the route group may be offered to a peering organization.

The aforementioned solution disturbs me in two points. First, since the destination group DG-1 and the route group RG-1 are not used for their primary reason (a destination group allows grouping of public identifiers that share a common set of routes, and a route group is generally used to group route records that may correspond to a same "destination" - that's why we share them as a block), it reveals a potential design issue. That's what I have qualified them as dummy before. That's the first impression I had when I heard this solution. The second point I want to raise concerns the complexity added by this solution. In this case, when an originating SSP wants to know the routes records associated to TN 1 for example, we directly see that there is a route record associated to it (RR 1). But, we don't know if this route record is accessible by the originating SSP. So, we need to get the enclosing destination group DG-1 and then the route group RG-1. We then check in its list of peering organizations if the originating SSP exists. Then, the route record RR 1 (obtained from the telephone number) is returned if the SSP is authorized. You will note that this processing is not the regular one described by SPPF. In general, we get the destination group associated to the queried public identifier, then the route group, and then the associated route records if authorized. Why do we need to use a different processing for the same kind of problem? After all, we just want to get the route records associated to the telephone number TN-1 in a user ENUM scenario (it's a banal scenario among many of them), as we want to get the route records associated to another public identifier in a regular scenario. That's what we have here: two symptoms that reveal a design issue.

Now, let's take a look at the UML class diagram present in the joined ProposedModel-SPPF.jpg file.

By using the abstraction defined by the abstract types PubIdentElement and RouteElement, it allows defining a many to many relationship between public identifier elements (i.e. single PI or destination group) and route elements (i.e. single route record or route group). This relationship is represented by the class-association RoutingAssoc. This association links zero or more public identifier elements to zero or more route elements. Also, to solve the scalability issue raised by Ken in the case one registrant organization has to offer a huge number of associations (previously route groups), we may use the same grouping concept for routing associations, represented by the AssocGroup type. Thus, we define a ShareableElement type that represents the basic entity that may be shared by a registrant organization.

 *   Public identifier - Route record (solving user ENUM issue plus the possibility to link a single RN/TNP/TNR to a route record)
 *   Public identifier - Route group (same as previous but with more than one route record)
 *   Destination group - Route record
 *   Destination group - Route group (regular scenario)

I don't think it's a big amount of change. The point here is to introduce an abstraction, and to use an intermediary type between the public identifier element and the route element. This intermediary type should be used for peering. After all, the valuable information that is shared is an association between public identifiers and routes, thus using a dedicated type for this association should be the solution.

Also, I still think the peering aspect of this protocol should be defined in a separated protocol that would support much more use cases than a simple offer/accept model. I think we should have two standards, each one focusing on a specific aspect of the problem, so we can decouple the two problems. Then, the users would have the choice to use the routing provisioning protocol or the peering protocol or both.

Maybe I'm missing something here, so if you see any issue (e.g. concerning scalability) caused by this data model, please let me know. I would be happy to hear your comments on these propositions.

Thanks

Mickael

________________________________
This e-mail message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Services.
Any unauthorised review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

---

From: Mickael Marrache <[email-masked]>
Date: Sat, 3 Mar 2012 19:55:00 +0200

Hi Ken,

“To meet the requirements deduced from the user ENUM use case, a direct
> association between the TN and route record types has been added”
>
> KJC:  Nothing has been “added”, the data model has been this way for at
> least two years now.
>

You're right. Sorry for saying something I didn't check.

> “So, one solution is to include these route records in a dummy (since the
> included route records have not common routes) destination group DG-1.
> Then, we also create a dummy (since it doesn't contain any route) route
> group RG-1 and associate it to DG-1. Then, the route group may be offered
> to a peering organization.”
>
>
>
> KJC: The Destination Group and the Route Group you refer to as “Dummys”,
> are not “Dummys” they are an integral and expected part of the data
> structure.
>
>
>
> “First, since the destination group DG-1 and the route group RG-1 are not
> used for their primary reason (a destination group allows grouping of
> public identifiers that share a common set of routes, and a route group is
> generally used to group route records that may correspond to a same
> "destination" - that's why we share them as a block), it reveals a
> potential design issue.”
>
>
>
> KJC:  The Route Group you refer to as “not contain any route rec” is not
> accurate.  It may or may not contain Route Recs.  It is up to the
> registrant and registrar to decide whether they wish to have route recs on
> a given route group, regardless of whether they have also decided to have
> Route Recs directly associated with a PI (i.e. in the user ENUM case, where
> some PIs will/may have Route Recs that contain info that is specific to
> that PI).  The model allows both, depending on the Registrar’s Registrant’s
> need.
>

So, the route group may or may not contain route records.

If it doesn't contain route records, I understand that it is only used to
share the route records directly associated to the PIs. In this case, do
you agree that it is not a *real *route group (i.e. a construct that allows
regrouping route records that correspond to a same destination)?

If it does contain route records, I understand that it plays two roles: it
allows sharing the route records directly associated to the PIs as
previously, and it allows sharing the route records that correspond to a
same destination.

KJC:  The Destination Group and Route Groups involved here _*do*_ in fact
> serve the purpose that they are designed to serve.  They allow the peering
> visibility of large numbers of public identities and their routing
> information to be controlled at an aggregate with just a few number of API
> calls, as apposed to millions (one per PI or Route Rec).  They allow the
> Destination Group to be associated or disassociated to from one or more
> Route Group objects in a single command as the need arises, they allow the
> Route Group to be offered/accepted in a single command, rather than one per
> route rec (which there would be millions of in the User ENUM case) or one
> per PI.  They Route Group allows further control of the visibility based on
> source-based routing, and other routing selection algorithms that, at this
> time, would be vendor specific since they are not in the protocol (e.g.
> time-of-day, cost, etc).
>

In the proposed model, this property is still true. It also allows the
peering visibility of a large number of public identifiers and their
routing information also using an aggregate (you will note that we didn't
remove the destination and route groups constructs) with a few number of
API calls. And I disagree when you say that the proposed model requires
offering to be done per route in the user ENUM case. When a huge number of
PIs are associated to route records directly (though a RoutingAssoc
element), you are not forced to offer each one of these associations, you
simply need to regroup them in an association group and to share this
association group, I don't see here any scalability issue.

Also, source based routing is also present in the proposed data model, in
the ShareableElement type.

“In this case, when an originating SSP wants to know the routes records
> associated to TN 1 for example….”
>
>
>
> KJC:  The second paragraph in your note attempts to describe part of the
> resolution process, I’ve included the first part of your statement above.
> It basically says that the resolution process is somehow different if Route
> Recs are directly associated with the PI than if they are associated with
> the Route Group.  This is not accurate.  First off, SPPP does not attempt
> to define how resolution servers must evaluate the data that SPP
> provisions.  Doing so would be folly, since TN resolution logic is much too
> involved, and often situation specific, including looking at data sources
> that do not even come in over SPPP (e.g. portability data, etc, etc).
> However, the basic logic involves (1) using the lookup key (e.g. a TN) and
> the source of the query to get the Destination Groups that contain that
> lookup key that are visible to that source based on the Route Groups that
> that source has accepted (or auto-accepted), (2) collecting the Route Recs
> that are on the Route Group(s) if any and/or the PI if any, (3) evaluating
> the Route Recs based on their priority (and other vendor specific
> resolution logic, which the protocol does not attempt to specify), then
> sending the collected Route Recs out in the resolution response.  Notice
> that there are not two different flows.
>

My comment for this point is related to the fact that a route group plays
the two roles mentioned previously. Playing what I call the basic role
(regrouping route records corresponding to the same destination) and the
disturbing role (allowing offer for route records directly associated to
PIs) is simply not intuitive. And, that's why David qualified this role as
a hack. It's not a derision for the current model, it is simply the fact
that there is something that is at the wrong place.

Also, I didn't get an answer concerning the possibility to associate a
single TNR, TNP or RN directly to one or more route records. Would we add
also a direct association from RN, TNR or TNP to route record?

KJC:  But from a bigger picture perspective, when the proposal was brought
> up yesterday, it was brought up under the guise that “the current data
> model is broken and it a hack in this area, so we need to do X, Y and Z”.
>  This is simply not accurate, as I’ve described above.  Secondly, the
> proposed alternative simply does not work in terms of scalability for the
> User ENUM use case.  The proposal would result in millions of Route Recs
> (since in the user enum case the Route Recs contain PI specific data)
> having to be offered and accepted.  So even the primary target use case of
> the proposal just does not work well.  So given that the current model is
> not “broken” and is not a “hack” and given that the new proposal does not
> scale for the user enum use case, why add in the additional complexity that
> results from the new proposal?
>

At this point, I still don't understand why the proposed model is not
accurate. I don't understand why millions of route records have to been
offered and accepted? I think grouping associations solves this problem.
Please, can you illustrate by a scenario or diagram (especially for the
User ENUM use case)?

I just want to precise that my comments are not intended to create
conflicts in any manner especially when I see that it's late to raise such
propositions and that the draft will become soon a RFC. I'm just trying to
add my efforts to this framework/protocol.

Thanks

Mickael

---

From: "Cartwright, Ken" <[email-masked]>
Date: Tue, 6 Mar 2012 17:54:47 -0500

Hi Mickael,

1) Maybe if you could provide/describe a new use case that the current model does not support then the need for the proposal would be clearer.

2) In the current model the Route Recs associated to a Route Group are intended to be applicableTo/appropriateFor multiple/many PIs.  A Route Rec directly associated to a PI is intended to be applicableTo/appropriateFor just that PI (e.g. contain PI specific info such as in user ENUM).  Given that, why would we also want the PIs that are directly associated to a PI to be part of a named group, so that they could be easily associated to multiple/many PIs.

3) And in regards to your statement... "Also, I didn't get an answer concerning the possibility to associate a single TNR, TNP or RN directly to one or more route records. Would we add also a direct association from RN, TNR or TNP to route record?"  Sorry, but I guess I missed that question in your original email.  I'm not fully clear on the question, but I think it may be answered by understanding point 2 above.
Ken

________________________________
From: Mickael Marrache [mailto:[email-masked]]
Sent: Saturday, March 03, 2012 12:55 PM
To: Cartwright, Ken; [email-masked]
Subject: Re: [drinks] SPPF changes proposal

Hi Ken,

So, the route group may or may not contain route records.
If it doesn't contain route records, I understand that it is only used to share the route records directly associated to the PIs. In this case, do you agree that it is not a real route group (i.e. a construct that allows regrouping route records that correspond to a same destination)?
If it does contain route records, I understand that it plays two roles: it allows sharing the route records directly associated to the PIs as previously, and it allows sharing the route records that correspond to a same destination.

In the proposed model, this property is still true. It also allows the peering visibility of a large number of public identifiers and their routing information also using an aggregate (you will note that we didn't remove the destination and route groups constructs) with a few number of API calls. And I disagree when you say that the proposed model requires offering to be done per route in the user ENUM case. When a huge number of PIs are associated to route records directly (though a RoutingAssoc element), you are not forced to offer each one of these associations, you simply need to regroup them in an association group and to share this association group, I don't see here any scalability issue.
Also, source based routing is also present in the proposed data model, in the ShareableElement type.

My comment for this point is related to the fact that a route group plays the two roles mentioned previously. Playing what I call the basic role (regrouping route records corresponding to the same destination) and the disturbing role (allowing offer for route records directly associated to PIs) is simply not intuitive. And, that's why David qualified this role as a hack. It's not a derision for the current model, it is simply the fact that there is something that is at the wrong place.
Also, I didn't get an answer concerning the possibility to associate a single TNR, TNP or RN directly to one or more route records. Would we add also a direct association from RN, TNR or TNP to route record?

At this point, I still don't understand why the proposed model is not accurate. I don't understand why millions of route records have to been offered and accepted? I think grouping associations solves this problem. Please, can you illustrate by a scenario or diagram (especially for the User ENUM use case)?

I just want to precise that my comments are not intended to create conflicts in any manner especially when I see that it's late to raise such propositions and that the draft will become soon a RFC. I'm just trying to add my efforts to this framework/protocol.

Thanks

Mickael

---

From: "Cartwright, Ken" <[email-masked]>
Date: Tue, 6 Mar 2012 18:26:27 -0500

Sorry, typo in item 2, it should read
2) In the current model the Route Recs associated to a Route Group are intended to be applicableTo/appropriateFor multiple/many PIs.  A Route Rec directly associated to a PI is intended to be applicableTo/appropriateFor just that PI (e.g. contain PI specific info such as in user ENUM).  Given that, why would we also want the Route Recs that are directly associated to a PI to be part of a named group, so that they could be easily associated to multiple/many PIs.

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Cartwright, Ken
Sent: Tuesday, March 06, 2012 5:55 PM
To: Mickael Marrache; [email-masked]
Subject: Re: [drinks] SPPF changes proposal

Hi Mickael,

Hi Ken,

Thanks

Mickael

---

From: Mickael Marrache <[email-masked]>
Date: Thu, 8 Mar 2012 15:50:19 +0200

Hi Ken,

1) Maybe if you could provide/describe a new use case that the current
> model does not support then the need for the proposal would be clearer.
>

As I understood from a previous response (not this one), the User ENUM
scenario consists of a set of subscribers of a certain SSP. Each of the
subscriber provides a certain route specific to it that is then associated
to its telephone number. So, the registrant SSP adds the concerned PIs, the
route records and the associations between them. Then, to share the route
records associated to these PIs, the registrant SSP groups the PIs in a DG,
creates a RG, associates the DG to the RG and shares the RG to a peering
organization. Optionally, the RG may have route records associated to it.
What is the meaning of these routes? If the routes corresponding to each PI
are shared, the peering organization can establish sessions directly to
these PIs? Do you mean these are general routes that may be used to
establish sessions to these PIs through the registrant SSP network?

Is there any case where a SSP would be interested to share only one PI to
another SSP ?
If yes, the current model requires creating a DG and a RG to enable peering
of the single PI. I'm just thinking about the way of finding a generic
model that is not built for specific needs, and I think the proposed model
is not so different that the current one, the main change concerns
introduction of an abstraction layer to deal with single elements and
groups of elements as a single unit.

2) In the current model the Route Recs associated to a Route Group are
> intended to be applicableTo/appropriateFor multiple/many PIs.  A Route Rec
> directly associated to a PI is intended to be applicableTo/appropriateFor
> just that PI (e.g. contain PI specific info such as in user ENUM).  Given
> that, why would we also want the Route Recs that are directly associated to
> a PI to be part of a named group, so that they could be easily associated
> to multiple/many PIs.
>

The proposed model doesn't force you to group route records directly
associated to a PI. You may associate the PI with each route record
separately. Then, if a registrant SSP wants to share these route records to
a peering organization, it may group them in an association group and share
this group.

3) And in regards to your statement… “Also, I didn't get an answer
> concerning the possibility to associate a single TNR, TNP or RN directly to
> one or more route records. Would we add also a direct association from RN,
> TNR or TNP to route record?”  Sorry, but I guess I missed that question
> in your original email.  I’m not fully clear on the question, but I think
> it may be answered by understanding point 2 above.
>

This is the same scenario as for the TN but this is not supported by the
current draft since the list of directly associated route records is
defined in the TN type and not in the PubIdType. What I mean is that we may
have a single RN, TNR or TNP associated to one or more PIs directly. And in
this case, why also to use grouping elements when they are not necessary?

Mickael

On Wed, Mar 7, 2012 at 1:26 AM, Cartwright, Ken <[email-masked]>wrote:

> **
>
> Sorry, typo in item 2, it should read ****
>
> 2) In the current model the Route Recs associated to a Route Group are
> intended to be applicableTo/appropriateFor multiple/many PIs.  A Route Rec
> directly associated to a PI is intended to be applicableTo/appropriateFor
> just that PI (e.g. contain PI specific info such as in user ENUM).  Given
> that, why would we also want the Route Recs that are directly associated to
> a PI to be part of a named group, so that they could be easily associated
> to multiple/many PIs.****
>
> ** **
>  ------------------------------
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Cartwright, Ken
> *Sent:* Tuesday, March 06, 2012 5:55 PM
> *To:* Mickael Marrache; ** [email-masked]
> **
> *Subject:* Re: [drinks] SPPF changes proposal
> ****
>
>  ** **
>
> Hi Mickael,****
>
> ** **
>
> 1) Maybe if you could provide/describe a new use case that the current
> model does not support then the need for the proposal would be clearer.***
> *
>
> ** **
>
> 2) In the current model the Route Recs associated to a Route Group are
> intended to be applicableTo/appropriateFor multiple/many PIs.  A Route Rec
> directly associated to a PI is intended to be applicableTo/appropriateFor
> just that PI (e.g. contain PI specific info such as in user ENUM).  Given
> that, why would we also want the PIs that are directly associated to a PI
> to be part of a named group, so that they could be easily associated to
> multiple/many PIs.****
>
> ** **
>
> 3) And in regards to your statement… “Also, I didn't get an answer
> concerning the possibility to associate a single TNR, TNP or RN directly to
> one or more route records. Would we add also a direct association from RN,
> TNR or TNP to route record?”  Sorry, but I guess I missed that question
> in your original email.  I’m not fully clear on the question, but I think
> it may be answered by understanding point 2 above.****
>
> Ken* *****
>
> ** **
>  ------------------------------
>
> *From:* Mickael Marrache [mailto:[email-masked]]
> *Sent:* Saturday, March 03, 2012 12:55 PM
> *To:* Cartwright, Ken; ** [email-masked]**
> *Subject:* Re: [drinks] SPPF changes proposal****
>
> ** **
>
> Hi Ken,****
>
> association between the TN and route record types has been added”****
>
> least two years now.****
> You're right. Sorry for saying something I didn't check.  ****
>
>  ****
>
> to a peering organization.”****
>
>  ****
>
> structure.****
>  ****
> potential design issue.”****
>
>  ****
>
> need.****
>  ****
> So, the route group may or may not contain route records.****
>
> you agree that it is not a *real *route group (i.e. a construct that
> allows regrouping route records that correspond to a same destination)?***
> *
>
> same destination.****
> ** **
> ** **
> time-of-day, cost, etc).****
>
> ** **
>
> association group, I don't see here any scalability issue.****
>
> the ShareableElement type.****
>
> ** **
>
> ** **
>
> associated to TN 1 for example….”****
>
>  ****
>
> that there are not two different flows.****
>
>  ****
>
> that there is something that is at the wrong place.****
>
> also a direct association from RN, TNR or TNP to route record?****
>
>  ****
>
> ** **
>
> results from the new proposal?****
>
>  ****
>
> Mickael****
> ** **
>  ------------------------------
>
> are not the intended recipient, please contact the sender by reply e-mail
> and destroy all copies of the original message.****
>
> ------------------------------
> are not the intended recipient, please contact the sender by reply e-mail
> and destroy all copies of the original message.
>
>

---

From: "Cartwright, Ken" <[email-masked]>
Date: Wed, 14 Mar 2012 11:04:25 -0400

Hi Mickael,

So is the new use case the "Want to be able to peer a single PI with a single SSP, in high volume?, Iow want to support many many one-to-one relationships between PIs and peering SSPs".  If so, then that is certainly not a use case that we ever worked toward, or documented in the use case document.  But the model certainly supports it in low volume.  And as described further below, this seems, from my point of view, to be a rare, low volume, and maybe even just a theoretical use case.

I tried to further answer some of your peering how-to and what-if inquiries below.

Thanks

Sent: Thursday, March 08, 2012 8:50 AM

Hi Ken,

As I understood from a previous response (not this one), the User ENUM scenario consists of a set of subscribers of a certain SSP. Each of the subscriber provides a certain route specific to it that is then associated to its telephone number. So, the registrant SSP adds the concerned PIs, the route records and the associations between them.
KJC:  The associations between them are attributes of the PI, so there is not a separate step required to create the PI and its association to a Route Rec, furthermore, the protocol specifically allows PIs and Route Recs to be created/modified/deleted in a single request/transaction if that is deemed appropriate by the provisioning client.  So this can all happen at once.
Then, to share the route records associated to these PIs, the registrant SSP groups the PIs in a DG, creates a RG, associates the DG to the RG and shares the RG to a peering organization.
KJC:  Again, it depends.  The flow can occur that way, but it is unlikely that it will happen that way, as a multi-step process.  More likely is that the provisioning client will have created the DG(s) and the RG(s) at some previous time.  And as new TNs are brought active they are just provisioned in, "into" that DG.  So it is effectively a one step process as new TNs are brought active.
Optionally, the RG may have route records associated to it. What is the meaning of these routes?
KJC:  I don't understand the question, it seems so basic that I must misunderstand.
If the routes corresponding to each PI are shared, the peering organization can establish sessions directly to these PIs? Do you mean these are general routes that may be used to establish sessions to these PIs through the registrant SSP network?
KJC:  Maybe, maybe not.  It all depends on who the registrant is and whether they have a network, who the registrant is and whether they have a network, etc, etc.  You're asking about all the difference use cases of how calls are routed using SIP and ENUM, and how other data about TNs is looked up and used?

Is there any case where a SSP would be interested to share only one PI to another SSP ?
KJC:  That would certainly be quite unusual.
If yes, the current model requires creating a DG and a RG to enable peering of the single PI.
KJC:  I've never seen the need for that arise in the real world.  And while it is certainly theoretically possible, it is, by definition, a very an unusual, low volume case.  So the model supports it, if it were to arise.  But even the proposed changes do not support that use case notably better than the current model.  The proposed model just adds another grouping mechanism and then proposes using that second grouping mechanism.
I'm just thinking about the way of finding a generic model that is not built for specific needs, and I think the proposed model is not so different that the current one, the main change concerns introduction of an abstraction layer to deal with single elements and groups of elements as a single unit.

KJC:  I don't agree with the characterizations in the above statement, "generic", "specific needs".
2) In the current model the Route Recs associated to a Route Group are intended to be applicableTo/appropriateFor multiple/many PIs.  A Route Rec directly associated to a PI is intended to be applicableTo/appropriateFor just that PI (e.g. contain PI specific info such as in user ENUM).  Given that, why would we also want the Route Recs that are directly associated to a PI to be part of a named group, so that they could be easily associated to multiple/many PIs.

The proposed model doesn't force you to group route records directly associated to a PI. You may associate the PI with each route record separately. Then, if a registrant SSP wants to share these route records to a peering organization, it may group them in an association group and share this group.

This is the same scenario as for the TN but this is not supported by the current draft since the list of directly associated route records is defined in the TN type and not in the PubIdType. What I mean is that we may have a single RN, TNR or TNP associated to one or more PIs directly. And in this case, why also to use grouping elements when they are not necessary?

KJC:  I can't agree that the grouping mechanism is not necessary for RNs, TNRs, or TNPs.  Many hundreds and thousands for those things are often given the same routes for one or more given SSPs.

Mickael

On Wed, Mar 7, 2012 at 1:26 AM, Cartwright, Ken <[email-masked]<mailto:[email-masked]>> wrote:
Sorry, typo in item 2, it should read
2) In the current model the Route Recs associated to a Route Group are intended to be applicableTo/appropriateFor multiple/many PIs.  A Route Rec directly associated to a PI is intended to be applicableTo/appropriateFor just that PI (e.g. contain PI specific info such as in user ENUM).  Given that, why would we also want the Route Recs that are directly associated to a PI to be part of a named group, so that they could be easily associated to multiple/many PIs.

________________________________
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Cartwright, Ken
Sent: Tuesday, March 06, 2012 5:55 PM
To: Mickael Marrache; [email-masked]<mailto:[email-masked]>

Hi Mickael,

________________________________
From: Mickael Marrache [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Saturday, March 03, 2012 12:55 PM
To: Cartwright, Ken; [email-masked]<mailto:[email-masked]>
Subject: Re: [drinks] SPPF changes proposal

Hi Ken,

Thanks

Mickael