Subject: [drinks] Summary of "Route Record Data Type" discussion

From: Alexander Mayrhofer <[email-masked]>
Date: Tue, 15 May 2012 09:55:48 +0000

As agreed during last week's Design Team call, i have summarized the discussion around the "route record data type" (SED data) below:

Originally, when we started with DRINKS (or, PEPPERMINT ;) the focus was to create a provisioning protocol mostly for ENUM-style services, and, hence, the data to be incorporated was mostly DNS-style data, specifically NAPTR records (NAPTRType) and NS-style delegations (NSType). In order to accomodate situations in which the protocol would be used to provision LUF-only services (returning an administrative domain identifier), the URIType was added, which together with an yet-to-defined URI scheme for SPID identification would allow to enter such SPIDs into SPP.

During the IETF Meeting in Paris, David Schwartz held a presentation including some considerations regarding the typing and nomenclature of those route record types:

http://tools.ietf.org/agenda/83/slides/slides-83-drinks-6.pdf (slides #3 to #7)

There was significant discussion around the issue, as noted in the meeting minutes, and the topic was finally deferred to the mailing list:

http://tools.ietf.org/wg/drinks/minutes?item=minutes-83-drinks.html

David later on proposed a change to the data model, which would provide a clear seperation between "target" and "location" type records:

http://www.ietf.org/mail-archive/web/drinks/current/msg01152.html

This proposal was then discussed extensively during the Design Team Call on April 4. There was consensus about clarifying intent and usage, however, there was also some doubt that the current proposal would provide that clarity. There was, however, consensus that renaming route record, maybe to SED record, was useful. 

During that call, Dean came up with the Idea to use RFC4501 to encapsulate the DNS data, and use URIs for all of the different record types. It was not immediately clear whether RFC 4501 would meet the needs.

Subsequent discussion took place on the mailing list, thread starts here:

http://www.ietf.org/mail-archive/web/drinks/current/msg01154.html

Among other things, Dean proposed to use URIs for all "record types" and also drop the seperate definition of an "egress route". Therefore the open issue seems to split up into the following "sub-issues":

1/ Whether a distinction between "Target" and "Location" type responses (LUF vs. LRF) would be needed on the provisioning side
2/ Whether "URI + regex" would (as the single "record type") satisfy all the requirements and use cases of the protocol, and hence the existing NAPTRType, NSType, URIType would be merged into a single "record type". 
3/ Whether an "egress route" would be covered by that "generic" record type as well.
4/ Whether the "Route Record" should be renamed into "SED record" - there seems to be rough concensus among the Design Team members that this should be done.

(Note that URNs are a subtype of an URI, so they would be included in the URI type as well).

For each of those sub-issues, our options are as follows:

1/ Target/Location subtyping:

1-1/ Keep as it is (no seperation). Understand the implications and limitations (as far as they affect the provisioning side, not the lookup side)
1-2/ Adopt the "split" of record type into "location" / "target" type. This would require (besides change to the data model, XML scheme and the document in general) to agree which record types would be available under which of the "supertypes" of records. 

(Personal note: I *think* that a split between location and target is only needed *if* the same record could be used in both situations. However, as Jon said during the Paris meeting, eg. a URI can only be dereferenced in the way it is specified for the URI scheme itself - does that still allow for ambiguity?)

2/ URI+regex instead of all other types?

2-1/ Keep the seperate subtypes.
2-2/ Replace all sub-types with a single "URI+regex" type. 

(Personal note: I understand that while RFC 4501 describes a URI scheme for DNS *queries*, it does not describe a URI scheme that would allow to include DNS *data* in a URI. Therefore, i'm not sure we would be able to put NAPTR and NS data into such a field. Also, there's a traditional concern about the ambigiuity of "open" URI fields, particularly since the "data:" URI scheme allows for arbitrary data without any clear semantics)

3/ Drop "egress route" in favor of a generic "SED Type" record

3-1/ Do nothing (keep egress route - probably clarify it's use case?)
3-2/ Drop Egress route, and explain how "normal" route records can supply this functionality

4/ Rename "Route Record" into "SED record"

4-1/ Keep old name
4-2/ Rename

I'm proposing to use the information above as a basis for tomorrow's Design Team call - hopefully we can solve that one issue during the discussion..

Alex

---

From: "Bhatia, Vikas" <[email-masked]>
Date: Wed, 16 May 2012 09:52:09 -0400

Thanks Alex. This was a useful summary on the historical perspective.

We can discuss on the rest, but specifically for the following:

>3-1/ Do nothing (keep egress route - probably clarify it's use case?) 3-2/ Drop Egress route, and explain how "normal" route records can supply this >functionality

I don't think dropping the "egress route" is an option. Not exactly sure what you meant by "normal" RRs, but none of the existing Route Record types (NAPTR, NS, URI) can fulfill the purpose of an egress route (in their current form). In my view, Egress Routes have a their own specific use case. David had proposed a Route Rule concept in Paris, but after giving that a thought I don't think Route Rule and Egress Route can be mixed either (because they are trying to create one structure for different use cases).

In interest of putting the Egress Route debate to bed, I would propose to modify Egress Route definition as follows (we had discussed this during the interim prior to last IETF and to be a general agreement - but we decided to wait until David's Route Rule proposal):

   <complexType name="EgrRteType">
     <complexContent>
           <extension base="sppfb:BasicObjType">
             <sequence>
                   <element name="egrRteName" type="sppfb:ObjNameType"/>
                   <element name="pref" type="unsignedShort"/>
                   <element name="regxRewriteRule"
                     type="sppfb:RegexParamType"/>
                   <element name="ingrRteGrp" type="sppfb:ObjKeyType"
                      minOccurs="0" maxOccurs="unbounded"/>
                        <element name="svcs" type="sppfb:SvcType" minOccurs="0"/>
                   <element name="ext" type="sppfb:ExtAnyType"
                     minOccurs="0"/>
             </sequence>
           </extension>
     </complexContent>
   </complexType>

Changes are:

"ingrRteRec" changed to "ingrRteGrp" - meaning Egress Route is associated to a Route Group
Added "svcs" element - indicates the ENUM service(s) to which Egress Route's "regxRewriteRule" should be applied (this will essentially drive what RRs within the RG need to be "egressed" through this Egress Route

Thanks,
Vikas

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Mayrhofer
Sent: Tuesday, May 15, 2012 5:56 AM
To: [email-masked]
Subject: [drinks] Summary of "Route Record Data Type" discussion

4-1/ Keep old name
4-2/ Rename

Alex

_______________________________________________
drinks mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/drinks

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: David Schwartz <[email-masked]>
Date: Wed, 16 May 2012 16:58:50 +0300

Hi Alex and thanks for this summary.

Here are a few comments (I am copying the relevant text)...

******************

DS: I agree regarding the mechanism to dereference a URI - the issue I see is that a target is nothing more than an opaque identifier and is not dereferenced in the first place. its not that I am worried about the question of "how" to dereference as much as I am worried about the question of "if" to dereference

******************

DS: Still wavering on this.

******************

DS: Egress route is semantically different than SED Type as its really just a rewrite rule that is there to modify an existing SED Type so no - we can't just drop. All I was saying was that the name "egress" implies only one kind of rule (that of an egress route) when in reality there are other uses for a rewrite rule (like some peering organization specific modification) and thus suggested we call it something more generic like "RouteRule" or now that Route is probably being deprecated in favor of SED --> "SEDRule"

******************

4-1/ Keep old name
4-2/ Rename

DS: Rename

---

From: David Schwartz <[email-masked]>
Date: Wed, 16 May 2012 17:03:08 +0300

Hi Vikas

I agree that it cannot be dropped as it is different from the others (see my previous post). 

Regarding the issue of whether or not its modifying a single record or group record I can go either way. My comment had more to do with the fact that egressRoutes have uses other than just egress routes.

:D

---

From: Daryl Malas <[email-masked]>
Date: Wed, 16 May 2012 10:36:12 -0600

David,

I have some concerns with this suggestion, "the fact that egressRoutes
have uses other than just egress routes."  If an egress route is used for
something other than an egress route, then it ceases to be an egress
route.  Egress route is used specifically for that -- that's why it's
called an egress route.  If you want a new requirement for some other
purpose, then I think it should be stated as such.  We need to be careful
not to overload and split hairs over semantics.  If you want new
functionality that is not covered by DRINKS, then propose a new
requirement.  The chairs can then work with the Ads to determine whether
or not it is in the scope of the charter.

--Daryl

On 5/16/12 10:03 AM, "David Schwartz" <[email-masked]> wrote:

>Regarding the issue of whether or not its modifying a single record or
>group record I can go either way. My comment had more to do with the fact
>that egressRoutes have uses other than just egress routes.
>
>:D
>
>>>3-2/ Drop Egress route, and explain how "normal" route records can
>>>supply this >functionality
>> 
>> I don't think dropping the "egress route" is an option. Not exactly
>>sure what you meant by "normal" RRs, but none of the existing Route
>>Record types (NAPTR, NS, URI) can fulfill the purpose of an egress route
>>(in their current form). In my view, Egress Routes have a their own
>>specific use case. David had proposed a Route Rule concept in Paris, but
>>after giving that a thought I don't think Route Rule and Egress Route
>>can be mixed either (because they are trying to create one structure for
>>different use cases).
>> 
>> In interest of putting the Egress Route debate to bed, I would propose
>>to modify Egress Route definition as follows (we had discussed this
>>during the interim prior to last IETF and to be a general agreement -
>>but we decided to wait until David's Route Rule proposal):
>> 
>> Added "svcs" element - indicates the ENUM service(s) to which Egress
>>Route's "regxRewriteRule" should be applied (this will essentially drive
>>what RRs within the RG need to be "egressed" through this Egress Route
>> 
>> Thanks,
>> Vikas
>> 
>> 
>> As agreed during last week's Design Team call, i have summarized the
>>discussion around the "route record data type" (SED data) below:
>> 
>> Originally, when we started with DRINKS (or, PEPPERMINT ;) the focus
>>was to create a provisioning protocol mostly for ENUM-style services,
>>and, hence, the data to be incorporated was mostly DNS-style data,
>>specifically NAPTR records (NAPTRType) and NS-style delegations
>>(NSType). In order to accomodate situations in which the protocol would
>>be used to provision LUF-only services (returning an administrative
>>domain identifier), the URIType was added, which together with an
>>yet-to-defined URI scheme for SPID identification would allow to enter
>>such SPIDs into SPP.
>> 
>> During the IETF Meeting in Paris, David Schwartz held a presentation
>>including some considerations regarding the typing and nomenclature of
>>those route record types:
>> 
>> There was significant discussion around the issue, as noted in the
>>meeting minutes, and the topic was finally deferred to the mailing list:
>> 
>> David later on proposed a change to the data model, which would provide
>>a clear seperation between "target" and "location" type records:
>> 
>> This proposal was then discussed extensively during the Design Team
>>Call on April 4. There was consensus about clarifying intent and usage,
>>however, there was also some doubt that the current proposal would
>>provide that clarity. There was, however, consensus that renaming route
>>record, maybe to SED record, was useful.
>> 
>> During that call, Dean came up with the Idea to use RFC4501 to
>>encapsulate the DNS data, and use URIs for all of the different record
>>types. It was not immediately clear whether RFC 4501 would meet the
>>needs.
>> 
>> Among other things, Dean proposed to use URIs for all "record types"
>>and also drop the seperate definition of an "egress route". Therefore
>>the open issue seems to split up into the following "sub-issues":
>> 
>> 1/ Whether a distinction between "Target" and "Location" type responses
>>(LUF vs. LRF) would be needed on the provisioning side
>> 2/ Whether "URI + regex" would (as the single "record type") satisfy
>>all the requirements and use cases of the protocol, and hence the
>>existing NAPTRType, NSType, URIType would be merged into a single
>>"record type".
>> 4/ Whether the "Route Record" should be renamed into "SED record" -
>>there seems to be rough concensus among the Design Team members that
>>this should be done.
>> 
>> 1-1/ Keep as it is (no seperation). Understand the implications and
>>limitations (as far as they affect the provisioning side, not the lookup
>>side)
>> 1-2/ Adopt the "split" of record type into "location" / "target" type.
>>This would require (besides change to the data model, XML scheme and the
>>document in general) to agree which record types would be available
>>under which of the "supertypes" of records.
>> 
>> (Personal note: I *think* that a split between location and target is
>>only needed *if* the same record could be used in both situations.
>>However, as Jon said during the Paris meeting, eg. a URI can only be
>>dereferenced in the way it is specified for the URI scheme itself - does
>>that still allow for ambiguity?)
>> 
>> (Personal note: I understand that while RFC 4501 describes a URI scheme
>>for DNS *queries*, it does not describe a URI scheme that would allow to
>>include DNS *data* in a URI. Therefore, i'm not sure we would be able to
>>put NAPTR and NS data into such a field. Also, there's a traditional
>>concern about the ambigiuity of "open" URI fields, particularly since
>>the "data:" URI scheme allows for arbitrary data without any clear
>>semantics)
>> 
>> I'm proposing to use the information above as a basis for tomorrow's
>>Design Team call - hopefully we can solve that one issue during the
>>discussion..
>> 
>> Alex
>> 
>> 
>> are not the intended recipient, please contact the sender by reply
>>e-mail and destroy all copies of the original message.
>>

---

From: David Schwartz <[email-masked]>
Date: Wed, 16 May 2012 19:50:11 +0300

Hi Daryl

I am sorry for not being precise. 

Modifying routes via regular expressions is not unique to egress routes and as such I feel that the name should be changed to a more generic RouteRewriteRule or SEDRewriteRule as opposed to EgressRoute. I think the name EgerssRoute is an unfortunate choice as it defines a use case more so than a data type. Additionally, egress routes are not really shareable (by definition two peering orgs cannot have the same egress route raising the question as to what this construct is doing in a shared registry) as opposed to routeRewriteRules which are. 

:D

On May 16, 2012, at 7:36 PM, Daryl Malas wrote:

>>> supply this functionality
>>>

---

From: "Bhatia, Vikas" <[email-masked]>
Date: Wed, 16 May 2012 23:59:15 -0400

David,

W.r.t the comment  "as such I feel that the name should be changed to a more generic RouteRewriteRule or SEDRewriteRule as opposed to EgressRoute"

-From what was proposed back in Paris (http://tools.ietf.org/agenda/83/slides/slides-83-drinks-6.pdf), it was not just a name change. Along with the name change from "EgrRteType" to "RteRuleType", there was an additional element introduced into --as proposed-- "RteRuleType" definition called "peeringOrg" - which along with the name change, significantly changes the semantics of this structure and makes it quite ambiguous imo. That is where my first and main concern is. Egress Routes are specific to an organization and do not have any peeringOrgs. Egress Routes solve a very specific use case of determining what Egress points within the operator's network are to be used for particular RR(s) within a RG (which may have been granted by a peeringOrg any way). What does it mean to have the proposed "RteRuleType" that has both a peeringOrg and a RR(or RG)? That leads to my second concern, which is that the actors are different as well. Egress Route rewrite regex will always be created by a peering org that is the recipient of a RG offer (to whom the route has been offered), whereas in your new use case of "like some peering organization specific modification" of the route, rule will be created by the peering org that has offered the route to various peers.

Imho, we are trying to create this generic structure to accommodate a different use case which muddles up and solves none of the use cases properly. If at all this has to be done, then structurally we probably would have a base RteRuleType, and then two derived types - one for Egress Route Rule and another derived type (for the new/different use case you have brought up). If we all want to take on this additional use case, then we can consider going this path.

W.r.t the comment " the question as to what this construct is doing in a shared registry.."
I am not sure if I understand this comment very well. Can you please elaborate? I thought this basic question of what Egress Route construct is doing in this registry should be have been discussed and agreed long back.

Thanks.

Vikas

-----Original Message-----
From: David Schwartz [mailto:[email-masked]]
Sent: Wednesday, May 16, 2012 12:50 PM
To: [email-masked]
Cc: Bhatia, Vikas; [email-masked]
Subject: Re: [drinks] Summary of "Route Record Data Type" discussion

Hi Daryl

:D

---

From: David Schwartz <[email-masked]>
Date: Tue, 22 May 2012 11:44:59 +0300

Hi Vikas and sorry for delay in responding to this. I only noticed this was in my inbox today.

Comments inline...

On May 17, 2012, at 6:59 AM, Bhatia, Vikas wrote:

> -From what was proposed back in Paris (http://tools.ietf.org/agenda/83/slides/slides-83-drinks-6.pdf), it was not just a name change. Along with the name change from "EgrRteType" to "RteRuleType", there was an additional element introduced into --as proposed-- "RteRuleType" definition called "peeringOrg" - which along with the name change, significantly changes the semantics of this structure and makes it quite ambiguous imo.

DS: If anything, having an element named PeeringOrg makes things more explicit. Let me try to be more specific. By definition, the egress route (other than the actual rewrite rule) has two pieces of information that need to be specified: (1) which route does this rewrite rule apply to and (2) for whom does this rule apply. The egress route solves (2) by simply having the organization needing this route modification provision (rant) the egress route. In a sense the "rant" of the egress route is not the owner of the route - but the owner of the modification rule so that instead of using the peeringOrg construct (which is there to define origination type stuff) for (2) it uses the rant for the same purpose which imho introduces more confusion (and I am aware that you can argue that rant is about "ownership" of things - not just routes or numbers but rules as well - still this is fuzzy). The mechanism I am proposing make all this much more explicit by solving (2) using the peeringOrg mechanism (whose meaning is more closely aligned to what you are trying to do) adding clarity not only to the definition of egress routes, but enabling as well other uses more suitable for a shared registry (see further comment below).

> That is where my first and main concern is. Egress Routes are specific to an organization and do not have any peeringOrgs. Egress Routes solve a very specific use case of determining what Egress points within the operator's network are to be used for particular RR(s) within a RG (which may have been granted by a peeringOrg any way). What does it mean to have the proposed "RteRuleType" that has both a peeringOrg and a RR(or RG)? That leads to my second concern, which is that the actors are different as well. Egress Route rewrite regex will always be created by a peering org that is the recipient of a RG offer (to whom the route has been offered),

> whereas in your new use case of "like some peering organization specific modification" of the route, rule will be created by the peering org that has offered the route to various peers.

DS: You say that like its a bad thing. I thought shared registries were meant to be provisioned by parties wishing offer routes to various peers?
> Imho, we are trying to create this generic structure to accommodate a different use case which muddles up and solves none of the use cases properly. If at all this has to be done, then structurally…

DS: I am sorry but I do not get this insistence on having use case specific constructs when the exact functionality can be achieved using a more generic approach.
> I am not sure if I understand this comment very well. Can you please elaborate? I thought this basic question of what Egress Route construct is doing in this registry should be have been discussed…

DS: If your only use case for this functionality is egress routes I do not understand why we would would be creating a mechanism whose sole purpose is to provision private information that is not to be shared with anyone else in protocol for provisioning of a shared registry? Imho, making the routeRule more generic and allowing for shared applications is probably the justification you need.

---

From: "Bhatia, Vikas" <[email-masked]>
Date: Wed, 23 May 2012 18:15:23 -0400

Sorry, but some of the basic concerns/queries I had with your new proposal are still not answered.

Let us try to argue this on the basis of few basic questions that need to be answered with your proposal:

>From one of your earlier emails, the new use case/scenario is "like some peering organization specific modification" of the route"

Based on that:

1. Can you please provide an example? It will be very helpful if you can walk us through a scenario for the case you have brought up. Along with helping us meaningfully interpret your proposal, it will also help answer the following questions.

2. As I understand, with the proposed change we will have more than one Rules that may be applicable to a RG during resolution (as opposed to currently when there is only one egress route rule is applicable for one RG at resolution). How then, does a resolution system determine the order/sequence in which these multiple rules that will be associated to a RG? Does that matter (probably..)?

3. How should a resolution system interpret it when both a peeringOrg and a RG is associated to the EgrRte? Egress routes, by definition, do not have a peering org. Does it mean, apply the route rule to all routes chosen for the peering Orgs or just that RG, or their intersection..very confusing construct?

4. W.rt to your comment:
" In a sense the "rant" of the egress route is not the owner of the route - but the owner of the modification rule so that instead of using the peeringOrg construct (which is there to define origination type stuff) for (2) it uses the rant for the same purpose which imho introduces more confusion"

I am not really sure what you mean. What "route" are you referring to above when you say " is not the owner of the route"? Rant of the egress route rule is the owner of the rule and is the only one who has knowledge on how to rewrite the ingress route to point to one of his egress routes.

5. Who are the actors for two types of rules?.."egress route rule" vs the new " peering organization specific modification"..Are not they mututally exclusive when "peeringOrgs" in the construct vs. when "RG" in the construct?

Thanks for helping understand your proposal better.

Vikas

-----Original Message-----
From: David Schwartz [mailto:[email-masked]]
Sent: Tuesday, May 22, 2012 4:45 AM
To: Bhatia, Vikas
Cc: [email-masked]; [email-masked]
Subject: Re: [drinks] Summary of "Route Record Data Type" discussion

Comments inline...