Subject: Re: [drinks] LUF and LRF (again)

From: Jean-Francois Mule <[email-masked]>
Date: Mon, 1 Mar 2010 05:49:33 -0700

Penn wrote:
> I think the issue is at least partly that of *distinguishing* LUF and
> LRF per the Speermint model in a drinks implementation. There are use
> cases in which one wants drinks to handle the LUF function and leave
> the
> LRF to other means and some in which the functions may be combined.

I agree with you Penn.  More efforts should be made in the documents to explain how the users of the drinks protocols may use them for LUF-only, or LUF+LRF.

I would note that the protocol proposed for client-to-registry communications in Stochholm has the means to distinguish these. A public identifier (say a TN or MDN) gets you to a name (route group name).  If that name is the target domain, or better, if a route group can point to a domain name object, then you have the LUF.
If folks want to further develop the SED, the route group name can point to other things.

Isn't that sufficient to address the needs to distinguish the two (along with more text and examples in the document)?

Jean-François

---

From: Jean-Francois Mule <[email-masked]>
Date: Mon, 1 Mar 2010 05:58:21 -0700

BTW - we are re-hashing things we have discussed before:
July 2008 - http://www.ietf.org/mail-archive/web/drinks/current/msg00023.html
http://www.ietf.org/mail-archive/web/drinks/current/msg00072.html
http://www.ietf.org/mail-archive/web/drinks/current/msg00109.html

and missing to point out how the currently proposed protocol requirements or draft specifications fail to meet them.

Can folks point out more specific changes they would like to see?

Jean-Francois.

Ray wrote:

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, February 18, 2010 9:22 AM
To: Cartwright, Kenneth
Cc: [email-masked]
Subject: Re: [drinks] LUF and LRF (again)

> There are cases where the LUF would
> just return some identifier that represents the WHO, while not
> returning the ultimate destination.

That's closest to my vision for DRINKS et al.

The LUF says "WHO", and in many cases "roughly WHERE".

That "roughly WHERE" corresponds to the "destination group" term that I introduced.

The LRF then turns "roughly WHERE" into "this particular ingress point".

> Mapping what is happening in the real world onto these Speermint
> abstractions is "interesting".

It sure is, although FWIW what I've described above is pretty much the proposed model for the UK number portability database, should OFCOM ever decide to mandate one.

Ray

--
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211

---

From: Jean-Francois Mule <[email-masked]>
Date: Mon, 1 Mar 2010 06:11:32 -0700

To be more specific, we had put a demarcation line in the data model of SPPP between the destination group and the route group. A route group mapping to a domain name would constitute the base for a LUF look-up.  A route group mapping to further object types (e.g. NAPTR or a more generic incarnation of a NAPTR) would provide some LRF support.

Do folks want more specific decoupling in the data model?
                One potential option is to create a domain name object that can be mapped to a route group - LUF only
                Another is to put a requirement to use the route group name (rteGrpName) as the target domain name for LUF-only provisioning
                Another is to create a new set of protocol operations for LUF-only

Thoughts appreciated.
Jean-François

From: Jean-Francois Mule
Sent: Monday, March 01, 2010 5:58 AM
To: [email-masked]'; Cartwright, Kenneth
Cc: [email-masked]
Subject: RE: [drinks] LUF and LRF (again)

Jean-Francois.

Ray wrote:

Ray

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Mon, 1 Mar 2010 09:36:22 -0500

My understanding of what the commenters are suggesting is that the LUF provisioning protocol not be baked in with the LRF provisioning protocol so that if one wants to just implements a LUF they do not have to concern themselves with the larger data model of the LRF.

Now a couple subtle aspects of the LUF LRF separation that I think most have not realized are:
(1)     Separation of the LUF and LRF from a provisioning perspective does not also *require* separation of the LUF and LRF from a resolution perspective (although it does allow it).
(2)     I *think* that separating the LUF and LRF from a resolution perspective strongly suggests that the resolution protocol for the LRF *not* be enum.  This is of course because LUF is supposed to return an AOR such that the domain name portion of the AOR indicates the current organization that services the address that was looked up.  And of course enum is unfortunately a resolution protocol that only support TNs as lookup keys.  But maybe I'm missing something.
Ken

________________________________
From: Jean-Francois Mule [mailto:[email-masked]]
Sent: Monday, March 01, 2010 8:12 AM
To: [email-masked]; Cartwright, Kenneth
Cc: [email-masked]
Subject: RE: [drinks] protocol commands to provision LUF-only data and LUF+LRF

Thoughts appreciated.
Jean-François

From: Jean-Francois Mule

Jean-Francois.

Ray wrote:

Ray

________________________________
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: Jean-Francois Mule <[email-masked]>
Date: Mon, 1 Mar 2010 08:06:25 -0700

Ken wrote:
> My understanding of what the commenters are suggesting is that the LUF
> provisioning protocol not be baked in with the LRF provisioning
> protocol so that if one wants to just implements a LUF they do not
> have to concern themselves with the larger data model of the LRF.

Right and this is what I meant by "demarcation" point and what I was asking about is whether a mapping between Route Group to a target domain would suffice to address the comment.
I do not understand what you mean by "not be baked in": to me, there could be one provisioning protocol and based on the schema sub-set you use, you exercise the LUF-only provisioning, or the LUF+LRF provisioning.  

> most have not realized are:
I'm not sure how those aspects on the resolution protocols help here.

> (1) Separation of the LUF and LRF from a provisioning perspective does
> not also *require* separation of the LUF and LRF from a resolution
> perspective (although it does allow it).
> (2) I *think* that separating the LUF and LRF from a resolution
> perspective strongly suggests that the resolution protocol for the LRF
> *not* be enum.  This is of course because LUF is supposed to return an
> AOR such that the domain name portion of the AOR indicates the current
> organization that services the address that was looked up.  And of
> course enum is unfortunately a resolution protocol that only support
> TNs as lookup keys.  But maybe I'm missing something.
How does this discussion influence the design here?

Jean-François

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Mon, 1 Mar 2010 10:12:46 -0500

(a) "not be baked in" means that they would be specified separately.

(b) the tangential points I made about the separation of LUF and LRF are just that, tangential.  Sorry if they clouded the discussion, but I sent them out before and garnered no responses to them.

-----Original Message-----
From: Jean-Francois Mule [mailto:[email-masked]]
Sent: Monday, March 01, 2010 10:06 AM
To: Cartwright, Kenneth; [email-masked]
Cc: [email-masked]
Subject: RE: [drinks] protocol commands to provision LUF-only data and LUF+LRF

Jean-François

---

From: Jean-Francois Mule <[email-masked]>
Date: Mon, 1 Mar 2010 08:32:11 -0700

Ken wrote
> (a) "not be baked in" means that they would be specified separately.

Let's drill down on what this would mean to make sure everyone pictures this and can throw in their 2 cents.

Based on the registry in production today, we have examples of folks looking at accommodating customers that need just LUF provisioning and customers that require LUF+LRF provisioning (on the same registry).

Use cases are:
	- SSP1 provisions LUF-only data in the registry.
SSP1 wants to provision the registry for LUF lookup only. SSP1 prefers LRF to its domain be done using RFC3263 because they manage their DNS and this is how they've chosen to manage location routing. So their peers must do 3263 to reach them.  
	- SSP2 prefers to provision LUF+LRF data in the registry.
SSP2 prefers to also put in the Registry which SBE to contact upon registry query.  They don't use 3263 (many SSPs don't for good or bad reasons), and they prefer to manage their "call routing" or SED in one place:  these TNs go into this destination group, and this destination group maps to this routing group which means that ingress route on my net.

Based on the above, I think this is not a goal to define two provisioning protocols, one for LUF prov and one for LUF+LRF.
The goal should be to make sure that:
	- folks that only want to provision LUF do it without having to know about LRF and do so with simplicity
(this gets down to potentially have simplified protocol operations for LUF prov only, kind of a mask for LUF usage)

	- folks that want to provision LUF+LRF do it simply too 
(and if these folks decide to implement DNS systems to manage LRF in their domains, then they can move from LUF+LRF provisioning to just LRF without protocol changes)

	- registry implementers that need to support both only implement one protocol, the syntax helps populate the registry and guide the resolution logic

	- OSS-BSS implementers that write clients to provision the registries can do so for LUF-only, or LUF+LRF and can re-use their application code across clients.

Thoughts?
Jean-François

---

From: "PFAUTZ, PENN L (ATTCORP)" <[email-masked]>
Date: Mon, 1 Mar 2010 15:59:18 -0500

In terms of rehashing, one question as I shake off the cobwebs....

If a  query returns NAPTR that resolves to the target SF URI, do we
consider LUF and LRF to have been done?

Penn Pfautz

AT&T Access Management

+1-732-420-4962

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Jean-Francois Mule
Sent: Monday, March 01, 2010 7:58 AM
To: [email-masked]; Cartwright,Kenneth
Cc: [email-masked]
Subject: Re: [drinks] LUF and LRF (again)

July 2008 -
http://www.ietf.org/mail-archive/web/drinks/current/msg00023.html

 

and missing to point out how the currently proposed protocol
requirements or draft specifications fail to meet them.

Jean-Francois.

Ray wrote:

From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Thursday, February 18, 2010 9:22 AM
To: Cartwright, Kenneth
Cc: [email-masked]
Subject: Re: [drinks] LUF and LRF (again)

That "roughly WHERE" corresponds to the "destination group" term that I
introduced. 

> abstractions is "interesting".

It sure is, although FWIW what I've described above is pretty much the
proposed model for the UK number portability database, should OFCOM ever
decide to mandate one. 

Ray

---

From: Adam Uzelac <[email-masked]>
Date: Mon, 1 Mar 2010 17:15:50 -0500

I am of the camp that the answer to this question is "YES".  Which makes
things confusing - Daryl addressed this in a SPEERMINT thread:

http://www.ietf.org/mail-archive/web/speermint/current/msg02629.html

So the query does resolve both, but doesn't have to. Shaking off the
cobwebs, but exposing the dust on this one unfortunately.

Adam Uzelac
Global Crossing

On Mon, Mar 1, 2010 at 3:59 PM, PFAUTZ, PENN L (ATTCORP) <[email-masked]>wrote:

>  In terms of rehashing, one question as I shake off the cobwebs….
>
>
>
> consider LUF *and* LRF to have been done?
>
>
>
> Penn Pfautz
>
> AT&T Access Management
>
> +1-732-420-4962
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Jean-Francois Mule
> *Sent:* Monday, March 01, 2010 7:58 AM
> *To:* [email-masked]; Cartwright,Kenneth
>
> *Cc:* [email-masked]
> *Subject:* Re: [drinks] LUF and LRF (again)
>
>
>
> BTW – we are re-hashing things we have discussed before:
>
> July 2008 -
> and missing to point out how the currently proposed protocol requirements
> or draft specifications fail to meet them.
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of [email-masked]
> *Sent:* Thursday, February 18, 2010 9:22 AM
> *To:* Cartwright, Kenneth
> *Cc:* [email-masked]
> *Subject:* Re: [drinks] LUF and LRF (again)
>
>
>
>
> _______________________________________________
> drinks mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/drinks
>
>

---

From: Sumanth Channabasappa <[email-masked]>
Date: Tue, 2 Mar 2010 10:45:15 -0700

The two use cases and suggested approach to have a single protocol to satisfy them makes sense to me. It should address what we have heard in terms of flexibility, without getting wrapped around with terminology, no? If I don't hear any objections, I will add this to the list of use cases and requirements I-D.

- S 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jean-Francois Mule
Sent: Monday, March 01, 2010 8:32 AM
To: Cartwright, Kenneth; [email-masked]
Cc: [email-masked]
Subject: Re: [drinks] protocol commands to provision LUF-only data and LUF+LRF

Ken wrote

Use cases are:

Based on the above, I think this is not a goal to define two provisioning protocols, one for LUF prov and one for LUF+LRF.
The goal should be to make sure that:
	- folks that only want to provision LUF do it without having to know about LRF and do so with simplicity (this gets down to potentially have simplified protocol operations for LUF prov only, kind of a mask for LUF usage)

	- folks that want to provision LUF+LRF do it simply too (and if these folks decide to implement DNS systems to manage LRF in their domains, then they can move from LUF+LRF provisioning to just LRF without protocol changes)

Thoughts?
Jean-François

---

From: David Schwartz <[email-masked]>
Date: Wed, 3 Mar 2010 15:20:41 +0200

I still see this as a three (not two) stage process that in many cases collapses into one or two steps.

* who - identity (e.g. AOR, SPID)
* where - Target (domain)
* how - Route 

Any attempt to bypass any of these steps in the design phase will only come back to bite us later,

D.
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of [email-masked] [[email-masked]]
Sent: Thursday, February 18, 2010 6:21 PM
To: Cartwright, Kenneth
Cc: [email-masked]
Subject: Re: [drinks] LUF and LRF (again)

Ray

---

From: David Schwartz <[email-masked]>
Date: Wed, 3 Mar 2010 15:45:12 +0200

Why is a comment like "domain name portion of the AOR indicates the current organization that services the address that was looked up" necessarily true? Why not just treat as an identity in the context of the specified domain without making a statement about the "servicing of the address" implying some routing responsibilities? Does a Tel uri constitue an AoR? many will argue - yes. I know this has been debated back and forth on many lists for some time and the fact that it is still unclear is related to this exact issue.

I believe that:
a. AoR does not necessarily have to have a domain
b. if it does - it still does not necessarily mandate routability - rather just specifying a relationship or context

I guess an analogy to this would be shipping vs billing address. When I identify myslef on ebay with a billing address (or context not unlike a domain associated with an AoR) - i.e. the David Schwartz living at ..., this in no way implies that I want you to necessarily send my package to this address.

D.
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Jean-Francois Mule [[email-masked]]
Sent: Monday, March 01, 2010 5:06 PM
To: Cartwright, Kenneth; [email-masked]
Cc: [email-masked]
Subject: Re: [drinks] protocol commands to provision LUF-only data and  LUF+LRF

Jean-François

---

From: Otmar Lendl <[email-masked]>
Date: Wed, 03 Mar 2010 17:56:43 +0100

> The LRF then turns "roughly WHERE" into "this particular ingress point". 

This LRF characterization only works if there is a direct interconnection
to the network serving the destination. In the transit case, the LRF
returns the ingress point of a suitable transit network.

Otherwise, yes, this makes sense.

/ol
-- 
// Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933 //

---

From: [email-masked]
Date: Wed, 3 Mar 2010 17:03:02 +0000

> Otherwise, yes, this makes sense.

Yes, you're right.

More accurately, I should have said that the LRF turns "roughly WHERE" 
into "the next hop".

Ray

---

From: Otmar Lendl <[email-masked]>
Date: Wed, 03 Mar 2010 18:31:18 +0100

On 01.03.2010 16:32, Jean-Francois Mule wrote:
> Based on the registry in production today, we have examples of folks
> looking at accommodating customers that need just LUF provisioning and
> customers that require LUF+LRF provisioning (on the same registry).
> 
> Use cases are: - SSP1 provisions LUF-only data in the registry. SSP1
> wants to provision the registry for LUF lookup only. SSP1 prefers LRF to
> its domain be done using RFC3263 because they manage their DNS and this
> is how they've chosen to manage location routing. So their peers must do
> 3263 to reach them. 

I think this is an important point to stress:

RFC3263 is a protocol to implement the LRF.

(just as basic ENUM is a simple LUF protocol)

My problem with this scenario is that RFC3263 assumes a fully
interconnected mesh of networks (even if used only inside a walled garden).

I strongly believe that this design decision inherent in 3263 makes it
unsuitable as real world LRF, except in very clearly defined special cases.
It simply fails in the presence of transit.

Rich got it IMHO right as he wrote "The data associated with the LRF is
then presumed to be a private data exchange between bilateral transit
partners [...]" on Feb 20th.

In any non-trivial interconnection scenario the LRF is a full blown routing
algorithm. It should be powered mainly via bi-lateral
reachability/ingress-point data exchanges that can include paths to
third-party destinations.

Putting static LRF data in the LUF registry is a crude hack that works only
within flat network structures. From a design point of view, it's like
putting Ethernet MAC addresses in the DNS instead of A records. Sure, it
can save one ARP lookup in certain cases, but at what loss of flexibility?

/ol
(see also
http://lendl.priv.at/blog/2009/08/10/whats-wrong-with-speermint-and-drinks/
and draft-lendl-speermint-background-02 for my PoV on this.)
-- 
// Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933 //

---

From: Jean-Francois Mule <[email-masked]>
Date: Mon, 8 Mar 2010 09:40:08 -0700

> consider LUF and LRF to have been done?
Yes, I think so.
LUF+LRF is done if the NAPTR contains the FQDN of the target SF host.

We (co-authors of the proto ID, copied on this message) are putting the following examples in the draft proto-02 that will be released today to help distinguish the LUF-only and LUF+LRF provisioning cases (per the mailing list requests).

--- folks who want LUF+LRF only operations
        <?xml version="1.0" encoding="UTF-8"?>
        <addRteGrpsRqst
               xmlns="urn:ietf:params:xml:ns:sppp:base:1"
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
               xsi:schemaLocation=
               "urn:ietf:params:xml:ns:sppp:base:1
               file:/ietf/example1.xsd">
            <basicRqst>
                <clientTransId>id-12317123</clientTransId>
                <minorVer>20</minorVer>
            </basicRqst>
            <rteGrp>
                <base>
                    <rantId>registrantID123</rantId>
                    <rarId>registrarId0</rarId>
                    <activDate>2010-05-04T18:13:51.0Z</activDate>
                    <delDate>2010-05-04T18:13:51.0Z</delDate>
                </base>
...-->          <rteGrpName>route_grp_1</rteGrpName>
...-->          <targetDomain>ssp1.example.com</targetDomain>
                <isInSvc>true</isInSvc>
            </rteGrp>
        </addRteGrpsRqst>
=> basically here, you add a route group that points to the target domain and stop there.

--- folks who want LUF+LRF provisioning operations
     <?xml version="1.0" encoding="UTF-8"?>
    <addRteGrpsRqst
           xmlns="urn:ietf:params:xml:ns:sppp:base:1"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xsi:schemaLocation=
           "urn:ietf:params:xml:ns:sppp:base:1
           file:/ietf/example2.xsd">
        <basicRqst>
            <clientTransId>id-12317123</clientTransId>
            <minorVer>20</minorVer>
        </basicRqst>
        <rteGrp>
            <base>
                <rantId>registrantID123</rantId>
                <rarId>registrarId0</rarId>
                <activDate>2010-05-04T18:13:51.0Z</activDate>
                <delDate>2010-05-04T18:13:51.0Z</delDate>
            </base>
            <rteGrpName>route_grp_1</rteGrpName>
...-->      <targetDomain>ssp1.example.com</targetDomain>
            <isInSvc>true</isInSvc>
...-->      <rteRec xsi:type="NAPTRType" ttl="1000" priority="200">
                    <order>10</order>
                    <pref>100</pref>
                    <flags>u</flags>
                    <svcs>E2U+sip</svcs>
                    <regx>
                        <ere>^(.*)$</ere>
                        <repl>sip:\1;[email-masked];</repl>
                    </regx>
            </rteRec>
            <isInSvc>true</isInSvc>
        </rteGrp>
    </addRteGrpsRqst>
==> here a NAPTR is provided.  The protocol will allow extensions for other types of route records.

Does this help "distinguishing" the two sets of use cases concretely?
Do folks have concerns with this approach?

Jean-Francois.

> From: PFAUTZ, PENN L (ATTCORP) [mailto:[email-masked]]
> Sent: Monday, March 01, 2010 1:59 PM
> To: Jean-Francois Mule; [email-masked];
> Cartwright,Kenneth
> Cc: [email-masked]
> In terms of rehashing, one question as I shake off the cobwebs..
>