Subject: [drinks] Some general comments on SPPF

From: David Schwartz <[email-masked]>
Date: Wed, 22 Feb 2012 15:06:29 +0200

Here are some additional comments to consider...

1. After spending considerable time analyzing this I am pretty convinced that peering should be completely removed from SPPF. I came to this conclusion afar going through some of the many peering scenarios and realizing that the current model supports a small subset of the cases. Many real world use cases are not addressed and the existing mechanism is simply incomplete. I spent many cycles trying to fix prior to just giving up - Here are just some of the sample use cases that lead to this conclusion:

* Sharing LUF in an open manner (with whomever wants it) using current mechanism (semantically, no peeringOrgs means NO sharing of rteGrp)
* peeringOrg would like to request LRF from org showing in its LUF that it has information for a PI
* Excluding a peer from receiving rteGrp information without knowing all parties that are ALLOWED to receive route information

IMHO an orthogonal peering model is required that can sit on top of SPPF.

2. EgressRoute is just a special case of a RouteRule and should be made more general. This is needed as well to address the route manipulation aspect of sorceIdent flag.

3. IsInService should be attribute of routeRecord as well

4. Need to have a URI type as a PI or else LUF resolution (URI) cannot be fed back into the system for LRF resolution.

5. Need to have in introduction option to just go identifier-> LRF without first LUF querying

6. Batch request should be an implicit subscription. New method NOTIFY should be sent when processing is done including summary of the operation.

7. Diagram in SPPF doc should be cleaned up
* remove extensions
* add missing arrows (TN and RR)
* add [0..n] on relevant arrows

---

From: David Schwartz <[email-masked]>
Date: Wed, 22 Feb 2012 15:13:33 +0200

I need to clarify item #4 below…

In the introduction there is mention of LUF followed by LRF lookup. While I am aware that this is a provisioning protocol, nonetheless, there needs to be a mechanism to provision an LUF --> LRF relationship. As the LUF resolution is a URI, what is missing is a LUF type PI.

:D

On Feb 22, 2012, at 1:06 PM, David Schwartz wrote:

<ATT00001..c>

---

From: Dean Willis <[email-masked]>
Date: Wed, 22 Feb 2012 09:57:29 -0600

>> 5. Need to have in introduction option to just go identifier-> LRF without first LUF querying

Can you clarify this one? I'm not exactly sure what you are talking about.

--
Dean

---

From: David Schwartz <[email-masked]>
Date: Wed, 22 Feb 2012 20:31:09 +0200

Hi Dean

This is taken from page 5 of the draft…

"A "terminating" SIP Service Provider (SSP) provisions SED into the

   registry to be selectively shared with other peer SSPs.
   Subsequently, a registry may distribute the provisioned data into
   local data repositories used for look-up queries (identifier -> URI)
   or for lookup and location resolution (identifier -> URI -> ingress
   SBE of terminating SSP).  In some cases, the registry may
   additionally offer a central query resolution service (not shown in
   the above figure)."

The part I was referring to was where it says  used for look-up queries (identifier -> URI) or for lookup and location resolution (identifier -> URI -> ingress SBE of terminating SSP)

imho there is a third option … identifier -> ingress SBE i.e. identifier->LRF directly without first looking up LUF.

:D

On Feb 22, 2012, at 3:57 PM, Dean Willis wrote:

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 23 Feb 2012 12:25:23 -0600

> imho there is a third option … identifier -> ingress SBE i.e. identifier->LRF directly without first looking up LUF.

But isn't that the same as identifier -> URI where the URI identifies the ingress SBE of the terminating SSP?

--
Dean

---

From: "Bhatia, Vikas" <[email-masked]>
Date: Fri, 24 Feb 2012 18:15:06 -0500

Please see below w.r.t #1 (follow up from discussion in last design call)...

Thanks,
Vikas

From: [email-masked] [mailto:[email-masked]] On Behalf Of David Schwartz
Sent: Wednesday, February 22, 2012 8:06 AM
To: [email-masked]
Subject: [drinks] Some general comments on SPPF

* Sharing LUF in an open manner (with whomever wants it) using current mechanism (semantically, no peeringOrgs means NO sharing of rteGrp)
* peeringOrg would like to request LRF from org showing in its LUF that it has information for a PI
[VB:] David, can you please elaborate on what you mean?

[VB:] After thinking some more about this after the last design call, I think we probably need to spend more time on this before we choose the direction. The cases listed here are an extension to the peering concept but that does not necessarily mean that the current protocol cannot be extended in future to meet these cases. The reason I say that is because cases listed here are not strictly offer/accept cases. The current offer key (RteGrpOfferKey) is strictly for offer/accept mechanisms. Like sharing RG in an open manner, means we want to have a RG that is like an 'open' RG. Anyone interested can use it. There is no strict offer or accept here. It is available for everyone. So an extension to the protocol *may* decide to have a RG Type of of 'open' RG.   Similarly for the case of where a RG is 'open' except for a certain peer is also not a offer/accept case. It's a case of Route that is 'open' to everyone except, so in this case the extension *may* add a attribute that represents a list of Org Ids that excluded from using the RG.

The point imho is that these cases do not necessarily present enough to justify that Peering, pertaining to offer/accept mechanism, should be taken out of the protocol. To alleviate some concerns. we can make the RG as a abstract base type and provide one concrete definition (the current one) of the RG. The other definitions of a RG (as pertaining to these new cases) will be extensible. Just some thoughts to consider for the group.

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