Subject: Re: [drinks] Some comments/nits on latest SPProv doc

From: David Schwartz <[email-masked]>
Date: Mon, 2 Jan 2012 18:27:36 +0200

Hi Vikas and thanks for responding. My comments are inline as well. I took the liberty of removing all parts of the email on which I did not have comments.

4.3 -> why isn't this a MUST?
[VB:] My understanding on this is that this is more of a performance optimization aspects for large datasets or constant small updates. Hence, it seems appropriate to be a SHOULD and not MUST.

DS: Not sure I agree. There are use cases for both in the use case doc so I still think it should be a MUST.

Destination Groups
6.1 -> I think that DG should have priority field as well. This allows to differentiate based on a a parameter other than route (e.g. cost)
[VB:] Can you please elaborate on this a bit more on what is the scenario? I thought the “priority” attribute on the RG determines the route to be used in situations where same DG is associated with multiple RGs.

DS: Sure. One of the things I argued for all along was the ability to prioritize DGs. The current design has the priority field in the RG which is in essence "passed onto" associated DG's. This assumes of course that the prime driver for prioritization is associated with routing information. I suppose the unfortunate use of the term "DestinationGroup" as opposed to a more generic "IdentifierGroup" is at the root of this (due obviously to the primary use for number lookups).  What if I want to prioritize LUF data that is associated only with a RantID and not necessarily with a route? Yes, I know I can use the existing mechanism - my only question is why? Why not have "priority" and "peering orgs" associated with the DG instead? What do you lose if you do it the way I propose? While on the topic I would also add that peering org should probably be grouped as well into PeeringOrgGroup so that I can share with group and not have to enter each org multiple times. Basically I am suggesting the following…

                             RouteG
                                    |
                                    |
                                   V

         PeerG ---->     DG (Priority)

                                    ^
                                    |
                                    |
                              PubID

Page 40 - When DG removed - it says PIs removed -> not references by PIs (see next comment about PIs)

PIs
Page 23 - why is a PI associated with only 1 DG? why not more? What if I have some TNRange and I want to have both "gold" and "silver" routes associated with it - how would I do this without having this TNR referencing more than one DG?
[VB:] A PIs association with its DG forms its primary key. There is a “priority” attribute in the RG definition. For “gold” and “silver” routes, same TNRange would be  created in two DGs with one of the DG associated to the “gold” route (with a higher priority) and other to the “silver” route (with a lower priority value).

DS: I see this differently. For the same reason you wouldn't delete an RG when a DG is deleted I would not delete a PI when a DG is deleted. The PI and the RG do not owe their existence to a DG. The DG is just a way to associate the two. In fact a PI may be reference multiple DGs just like an RG may reference multiple DGs. If you want to speak of deleting PIs I would suggest a reference count mechanism which would make sure that PIs are deleted when a DG that is the ONLY one being referred to by the PI is deleted. I know this is not the way it is currently implemented - I just don't like the Asymmetry.

Page 24 -> isn't the idea of a RouteGroup to "group" route records"? Why then in the definition of a TN do we refer to an rrRef instead of an rgRef? The description does say "one or more" rrRefs which would imply to me that this could be a rgRef
[VB:] Sorry, but two parts of this comment seem unrelated.  Yes, the idea of RG is to associate a set of Pub Ids (DG) that share a common routing information, to the set of Route Records that form that routing information.  TN association to RG is via the DG. TN also refers to rrRef for situations where the routing information may be unique to a particular TN. We need to correct the description however to say “zero or more” and not “one or more”. May be that caused the confusion.

DS: I guess I never understood this use case anyway (unless we are talking about an AOR identifier). Assuming a TN like it says - is it not possible to have a failover route for a single TN? Am I forced to create a DG for this? Like I said - I don't get this use case.

SourceID
Page 30 - Why not simply a URI instead of enumeration as regex can deal with parts of URI. We all know that in the end the source information will be represented in the DNS request using a URI.
[VB:] Source information match can be done via the IP where the request is coming from (which may not be in the URI), root domain or the URI itself. In that sense having source identity scheme as one of “uri”, “ipaddress”, or “rootDomain” seems valid. Can you elaborate further? Design Team?

DS: I am fine with this. It was more of a comment that the "information" revealing who the "source" is will probably take the form of a URI.

Page 38 - why isn't egrRte associated with RG?
[VB:] It probably was just a design decision. Having egrRte associated with a RG would mean that egrRte definition would also need to have an optional “svcs” element to defines the type of ENUM service(s) supported by the route. For situations where many ingress routes share the same egress route, right now there will be an association between egress route object and all RRs  that are part of the RG. Design Team?

DS: My point exactly - seems kind of inefficient. RGs represent logical ingress points while the RRs are the actual IPs. It stands to reason that an egress route will apply to all RRs in an RG.

---

From: "Bhatia, Vikas" <[email-masked]>
Date: Tue, 17 Jan 2012 13:57:05 -0500

Please see comments inline. We should discuss some of these items in the next design team meeting.

Thanks,
Vikas

From: David Schwartz [mailto:[email-masked]]
Sent: Monday, January 02, 2012 11:28 AM
To: Bhatia, Vikas
Cc: [email-masked]
Subject: Re: Some comments/nits on latest SPProv doc

[VB:] Yeah, both large datasets and constant small updates may occur via sppp. The use case for large sets (Non-real-time bulk provisioning) is listed as an optional use case in the usecases document. W.r.t small constant updates, for transport protocols that do not support long-lived connections, the implications are that such operations would have the associated cost of less than optimal performance. Therefore I still think it is fine as a SHOULD. Let us discuss in the next design team meeting.

Destination Groups
6.1 -> I think that DG should have priority field as well. This allows to differentiate based on a a parameter other than route (e.g. cost)
[VB:] Can you please elaborate on this a bit more on what is the scenario? I thought the "priority" attribute on the RG determines the route to be used in situations where same DG is associated with multiple RGs.

DS: Sure. One of the things I argued for all along was the ability to prioritize DGs. The current design has the priority field in the RG which is in essence "passed onto" associated DG's. This assumes of course that the prime driver for prioritization is associated with routing information. I suppose the unfortunate use of the term "DestinationGroup" as opposed to a more generic "IdentifierGroup" is at the root of this (due obviously to the primary use for number lookups).  What if I want to prioritize LUF data that is associated only with a RantID and not necessarily with a route? Yes, I know I can use the existing mechanism - my only question is why? Why not have "priority" and "peering orgs" associated with the DG instead? What do you lose if you do it the way I propose? While on the topic I would also add that peering org should probably be grouped as well into PeeringOrgGroup so that I can share with group and not have to enter each org multiple times. Basically I am suggesting the following...

                             RouteG
                                    |
                                    |
                                   V

                                    ^
                                    |
                                    |
                              PubID

[VB:] How would we achieve LUF in this representation? We would have to add an association between DG and RteRec in order to get the target domain for the PIs in the DG. Imo, we achieve the same thing by having a RG that provides linkage between one or many DGs and one or many RteRecs. Looking at the way it currently is (.i.e.  RGs) it is better and more efficient since many DGs having the same LUF or LRF need not be associated to same RteRecs redundantly. The idea of PeeringOrgGroup has both pros and cons. You are right, it may help in situations where there are many peering orgs to be associated to RGs. But it will also require users to create PeeringOrgGroup when they really have only one peering org to be associated. To me it seems more like an implementation decision and I am not sure if this necessarily needs to be built into the protocol.

PIs
Page 23 - why is a PI associated with only 1 DG? why not more? What if I have some TNRange and I want to have both "gold" and "silver" routes associated with it - how would I do this without having this TNR referencing more than one DG?
[VB:] A PIs association with its DG forms its primary key. There is a "priority" attribute in the RG definition. For "gold" and "silver" routes, same TNRange would be  created in two DGs with one of the DG associated to the "gold" route (with a higher priority) and other to the "silver" route (with a lower priority value).

[VB:] If I understand correctly, you are proposing to have the DGs to have an 'association' type relationship to PIs instead of having the DG-PI primary key.  Again, imo, these is one of those things which was a design decision that could have gone either way. Not sure if there were discussions around this in past. Seems what you are proposing would work as well.

Page 24 -> isn't the idea of a RouteGroup to "group" route records"? Why then in the definition of a TN do we refer to an rrRef instead of an rgRef? The description does say "one or more" rrRefs which would imply to me that this could be a rgRef
[VB:] Sorry, but two parts of this comment seem unrelated.  Yes, the idea of RG is to associate a set of Pub Ids (DG) that share a common routing information, to the set of Route Records that form that routing information.  TN association to RG is via the DG. TN also refers to rrRef for situations where the routing information may be unique to a particular TN. We need to correct the description however to say "zero or more" and not "one or more". May be that caused the confusion.

[VB:] Yeah, a single TN can be directly associated to a RteRec, without needing to create a DG for that. I believe this is the user enum case.

SourceID
Page 30 - Why not simply a URI instead of enumeration as regex can deal with parts of URI. We all know that in the end the source information will be represented in the DNS request using a URI.
[VB:] Source information match can be done via the IP where the request is coming from (which may not be in the URI), root domain or the URI itself. In that sense having source identity scheme as one of "uri", "ipaddress", or "rootDomain" seems valid. Can you elaborate further? Design Team?

DS: I am fine with this. It was more of a comment that the "information" revealing who the "source" is will probably take the form of a URI

[VB:] Ok.

Page 38 - why isn't egrRte associated with RG?
[VB:] It probably was just a design decision. Having egrRte associated with a RG would mean that egrRte definition would also need to have an optional "svcs" element to define the type of ENUM service(s) supported by the route. For situations where many ingress routes share the same egress route, right now there will be an association between egress route object and all RRs  that are part of the RG. Design Team?

[VB:]  RRs in a RG may be supporting different services (mms, sip etc), and as such it is not necessary that an egress route applies to all RRs in the RG. That is one advantage of a direct association between EgrRte and RR (same EgrRte can be used for all associated RteRecs without worrying about the services those RteRecs are supporting).  I am fine either way on this.

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