Subject: Re: [drinks] Comment on today's drinks discussion

From: "Cartwright, Kenneth" <[email-masked]>
Date: Mon, 3 Aug 2009 15:24:34 -0400

Thanks.  Can you please provide more detail on this so that we are able to assess whether we need to add something to the protocol to support it.  More specifically:

1) Numbers can certainly be "resold" as you say (e.g. an MVNO).  But what impact does this have on the features of the protocol?  I do not think the Use Case document contains use cases that document what you may be getting at.
2) What exactly do you mean by "SOME provisioning responsibility goes with the resale".
3) You separately ("there are also cases") refer to the fact that there are "chains of resellers" and "the services each can provision may be different".  Can you be more specific with what you mean by "services" in the above statement?

Thanks

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Thursday, July 30, 2009 2:55 AM
To: 'Guyton, Deborah A'; 'PFAUTZ, PENN L, ATTCORP'; 'Alexander Mayrhofer'; [email-masked]
Subject: Re: [drinks] Comment on today's drinks discussion

I got into this with some real world issues where numbers are resold, and
SOME provisioning responsibility goes with the resale.  There are also cases
where there is a chain of resellers, and the services each can provision may
be different.

Brian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Guyton, Deborah A
> Sent: Thursday, July 30, 2009 2:42 AM
> To: 'PFAUTZ, PENN L, ATTCORP'; Alexander Mayrhofer; [email-masked]
> Subject: Re: [drinks] Comment on today's drinks discussion
>
> Hi Penn,
> Hopefully I can clear up one item quickly. The idea of "Registrant" is
> the notion that a "Registrar" who is the "holder" of the data or
> carrier of record, for example, might outsource the administration of
> that data to a "Registrant".   An analogy in today's world is that some
> companies do not  manage their own data in LERG but outsource to a
> third party.  It may be necessary to allow for an individual
> administrator "Joe Administrator" to be the responsible individual for
> administering that data - hence having a login and password
> (particularly for a GUI) but could be a login and password for a
> service provisioning interface. For data issues, you might need to
> resolve with a person.
> If administration is done as it is today, perhaps for AT&T, Registrar =
> AT&T and Registrant = AT&T.
> Hope that helps.
> Debbie
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of PFAUTZ, PENN L, ATTCORP
> Sent: Wednesday, July 29, 2009 4:39 PM
> To: Alexander Mayrhofer; [email-masked]
> Subject: Re: [drinks] Comment on today's drinks discussion
>
> Alex:
> My concerns are not entirely with respect to the current draft but some
> of the directions that the discussion during the WG session suggested
> the work might be taking.
>
> I've had a lingering concern about the disconnect between what
> Speermint
> has proposed (LUF/LRF)and the route that drinks has taken. Since the
> will of the design team seemed to be to get on with a simple protocol
> directed toward provisioning DNS RRs I let that ride. Monday's session,
> however brought up things like more abstraction of routing elements
> which suggests to me assumptions about the nature of interconnections
> and my issues with the original ESPP I-D.
>
> Brian Rosen's comment about number "ownership" relations also seemed to
> suggest another complexity that the protocol would try to incorporate.
>
> I get concerned about a protocol that either makes a lot of specific
> assumptions about the nature of the registry and the interconnection
> framework and/or becomes bloated by trying to incorporate the panoply
> of
> possible cases.
>
> A more specific issue - the definition of Registrant as an "end user" -
> this is at least confusing in the context of Infrastructure vs. End
> User
> ENUM.
>
> I'll keep watching how things evolve. It may be that others conclude
> they need the added complexity but I wanted to be forthright about my
> position.
> Thanks for listening.
>
>
> Penn Pfautz
> AT&T Access Management
> +1-732-420-4962
>
> -----Original Message-----
> From: Alexander Mayrhofer [mailto:[email-masked]]
> Sent: Monday, July 27, 2009 12:56 PM
> To: PFAUTZ, PENN L, ATTCORP; [email-masked]
> Subject: RE: [drinks] Comment on today's drinks discussion
>
> > I for one have concerns about how useful the resulting
> > protocol is likely to be, at least for my company's likely
> > applications.
>
> Penn,
>
> Thanks for that "wakeup call" - as we said we want definitely a
> deployable protocol, so i'm concerned about your statement - could you
> elaborate of what properties of the current draft would make it less
> useful for your company's applications, and what could be done to make
> it fit better?
>
> Thanks
>
> Alex
> _______________________________________________
> drinks mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/drinks
> _______________________________________________
> drinks mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/drinks

_______________________________________________
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: "Cartwright, Kenneth" <[email-masked]>
Date: Mon, 3 Aug 2009 15:27:54 -0400

Thanks for the feedback.

1) How do you feel that we are not supporting the LUF/LRF concepts?  Can't a Destination Group and its associated Route Group be used to return a URI whose domain name is the one that requires as an output of the LUF?  Or is there something that I'm missing?

2) What specifically would need to be done to the protocol to make it more useful for your company's likely applications?

Ken

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of PFAUTZ, PENN L, ATTCORP
Sent: Monday, July 27, 2009 12:46 PM
To: [email-masked]
Subject: [drinks] Comment on today's drinks discussion

I've been away from the design group for a while since the focus seemed to shift more to lower level design issues outside of my bailiwick but I came away from today's IETF discussion with an uncomfortable feeling about where the drinks effort is heading.
One the one hand I feel that some of the issues we agreed to set aside to narrow scope (LUF/LRF) are coming back to haunt us and on the other that the effort is straining as Otmar suggests to accommodate more and more complexity that should, perhaps be handled elsewhere. Perhaps these are different sides of the same coin.
I for one have concerns about how useful the resulting protocol is likely to be, at least for my company's likely applications.

Penn Pfautz
AT&T Access Management
+1-732-420-4962

________________________________

---

From: "PFAUTZ, PENN L, ATTCORP" <[email-masked]>
Date: Mon, 3 Aug 2009 15:37:00 -0400

Ken:
1) My take was that Speermint separates LUF/LRF. The protocol as defined
can certainly support returning a LUF output, but folks seemed to want
to push further than that or not make any distinction between the two
functions.
 
2) my concern is the increasing complexity takes the protocol beyond our
needs which might lead us to look towards something simpler.
 
Penn Pfautz
AT&T Access Management
+1-732-420-4962

From: Cartwright, Kenneth [mailto:[email-masked]] 
Sent: Monday, August 03, 2009 3:28 PM
To: PFAUTZ, PENN L, ATTCORP; [email-masked]
Subject: RE: Comment on today's drinks discussion

Thanks for the feedback.

1) How do you feel that we are not supporting the LUF/LRF concepts?
Can't a Destination Group and its associated Route Group be used to
return a URI whose domain name is the one that requires as an output of
the LUF?  Or is there something that I'm missing?

2) What specifically would need to be done to the protocol to make it
more useful for your company's likely applications?

Ken

From: [email-masked] [mailto:[email-masked]] On Behalf
Of PFAUTZ, PENN L, ATTCORP
Sent: Monday, July 27, 2009 12:46 PM
To: [email-masked]
Subject: [drinks] Comment on today's drinks discussion

I've been away from the design group for a while since the focus seemed
to shift more to lower level design issues outside of my bailiwick but I
came away from today's IETF discussion with an uncomfortable feeling
about where the drinks effort is heading.

One the one hand I feel that some of the issues we agreed to set aside
to narrow scope (LUF/LRF) are coming back to haunt us and on the other
that the effort is straining as Otmar suggests to accommodate more and
more complexity that should, perhaps be handled elsewhere. Perhaps these
are different sides of the same coin. 

I for one have concerns about how useful the resulting protocol is
likely to be, at least for my company's likely applications.

Penn Pfautz

AT&T Access Management

+1-732-420-4962

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: "Cartwright, Kenneth" <[email-masked]>
Date: Mon, 3 Aug 2009 15:41:13 -0400

Thanks.

1)       The Speermint Arch doc only separates them logically.  It dose not separate them physically.  So Speermint certainly allows that a single piece of software could be both LUF and LRF or just LUF or just LRF.  So I think we're ok on that front.
2)       What complexity has "increased"?  iow, do you have some specific recommendations?

Ken

________________________________
From: PFAUTZ, PENN L, ATTCORP [mailto:[email-masked]]
Sent: Monday, August 03, 2009 3:37 PM
To: Cartwright, Kenneth; [email-masked]
Subject: RE: Comment on today's drinks discussion

Ken:
1) My take was that Speermint separates LUF/LRF. The protocol as defined can certainly support returning a LUF output, but folks seemed to want to push further than that or not make any distinction between the two functions.

2) my concern is the increasing complexity takes the protocol beyond our needs which might lead us to look towards something simpler.

Penn Pfautz
AT&T Access Management
+1-732-420-4962

Ken

Penn Pfautz
AT&T Access Management
+1-732-420-4962

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 10 Aug 2009 17:40:37 +0200

PFAUTZ, PENN L, ATTCORP wrote:
> 
> I've had a lingering concern about the disconnect between what Speermint
> framework and/or becomes bloated by trying to incorporate the panoply of
> possible cases.
> 

Penn,

one of the problem I see is that these assumptions regarding the
"interconnection framework" are never spelled out. I don't see a vision on
how this might all fit together other than in very restricted situations.

Anyway, on a recent train ride I tried to write up a summary on what bugs
me about the Speermint/Drinks design. Here it is:

--------------------------------------

Some comments on the direction Speermint and Drinks are taking

First of all, why do we need these WGs at all? The quick answer is that
VoIP interconnection based on plain SIP and ENUM did not work out as
envisioned by the authors of the respective RFCs. There are a number of
reasons for that (see draft-lendl-speermint-background), and I don’t expect
that the IETF can do anything to change this.

What happens in the ITU/ETSI/3GPP area? The PSTN interconnection used to be
simple before the era of telecom liberalization: you had one incumbent per
country and close to a full mesh of interconnection links between all
countries. In the GSM world, the possibility of roaming led to a large
number (scaling with O(n*n)) of contracts between operators. In both the
fixed line business, as well as in the mobile telephony world, the number
of operators has markedly increased over the last years. A full mesh of
links just is not possible any longer. Even if the underlying network does
not need dedicated links any more, just doing contracts between all
possible pairs is no longer a viable option. Recent developments in the GRX
and IPX demonstrate this: The introduction of "hubs" was necessary to get
the quadratic scaling under control. The time of full meshes is over.

Call routing was rather simple in the full mesh world (be it PSTN or
RFC3263 SIP), it only needed some directory service to map Public
Identities (PI = phone numbers or SIP URIs) to operators. In a lot of
cases, these directories are static simple mappings like "route anything
starting with +49 to Deutsche Telekom".

This is no longer sufficient. Any solution to the current world-wide call
routing problem needs to cope with arbitrary interconnection graphs, not
just the trivial case of full meshes. A directory will not suffice any
more: we need a full blown routing algorithm.

I repeat: The current graph of interconnection between carriers has no
special properties any more. We have a text-book routing problem to solve.

This is not what Speermint is supposed to solve. As the name says: It is
supposed to do “peering” and not “routing”. In other words, Speermint
covers what two operators need to do to exchange calls between their direct
customers.

As the need to cover transit is clear, it has crept into a good number of
Speermint documents. This just amounts to “we need to consider these
scenarios”, but not to “here is how you solve them”.

Why is Speermint restricted to peering? My guess is the following:

    * The driving force behind the establishment of this working group is
the set of US MSOs. Their motivation is simple: enable direct call routing
amongst them. They do not care about transit.

    * Doing a routing protocol for VoIP violates the IETF end-to-end
principle and is thus not politically correct.

    * A full routing architecture plus routing protocol for VoIP is a huge
task and to be successful needs buy-in from traditional carriers. This is
more than the IETF is willing to tackle.

    * Peering can be stacked on existing protocols as implemented in the
SIP devices: all the reachability/routing information is stored in ENUM
trees which the SIP devices query. The only protocol work relates to how
these ENUM trees get populated. Thus DRINKS.

What’s not to like?

    * Transit will be back.

      It’s an illusion that we can build a system solely for peering
setups. This will get used for transit. The foundations build by Speermint
will not be able to really support transit. I predict utterly messy and
unstable deployments down the road as transit will be bolted on peering.

      It is far better protocol design to see peering as a simple special
case of transit.

      What DRINKS is doing is the SIP equivalent of a provisioning protocol
to drive proxy-ARP servers for the interconnection of LANs. Nice and simple
if everybody you every want to reach is just a hop away, but complete
unsuitable for transit.

    * ENUM will not be enough.

      ENUM is a simple lookup protocol: The input is an E.164 number and
the result is an ordered set of service-type/URI pairs. ENUM is not a SIP
device control protocol. It is way too limited in the information the SIP
device can pack into the _query_ (e.g.: source URI, source trunk
information, SIP device ID, media requested, ...). You can fudge more
information into the ENUM _answers_ by excessive use of URI parameters, but
the query is limited by the underlying DNS protocol.

    * Excessive use of Registries.

      The LERG and LNP databases are know solutions. The default solution
for data-interchange problems in the PSTN world seems to be registries.
(Remember the old adage of a problems looking like nails when all you have
are hammers?)

      In the Internet architecture, central registries are sometimes a
necessary evil and are kept as small as possible. In the VoIP routing case,
registries are certainly part of a solution, but only to manage a shared
namespace (domain registries for URIs and ENUM registries for E.164 numbers).

    * LUF / LRF confusion.

      In a rare moment of sanity, Speermint came up with the distinction
between LUF and LRF. In a nutshell: the LUF (Lookup Function) maps the
public identifier to some aggregation concept like "destination group",
"routing key", "destination domain",... whereas the LRF (Location Routing
Function) take this Identifier as input an finds the next SIP hop towards
that destination.

      This is a common concept in the Internet: typically a domain-name is
first mapped to an IP address, and then the IP routing algorithm finds the
next hop towards the host offering services for that domain.

      The basic concept behind this is the difference between a "name"
(identifying what you want, regardless where it is) and an "address"
(identifying where something is, preferably amenable to aggregation). The
result of the LRF is the Session Establishment Data (SED) which is a
"route" (identifying the next hop towards the destination).

      The LUF is best implemented by an on-demand lookup function to
central database (which does not preclude local replicas for performance
reasons). The LUF is querier-independent; everybody will get the same answer.

      The LRF is the lookup into a local routing database. No external
database needs to be involved. But you need either a lot of manual work or
a routing protocol between the interconnection-partners to build up the
local routing tables.

    * Too much information in the Registry.

      As should be clear from the preceding remarks, I consider it to be a
serious mistake that the current DRINKS design completely merges LUF and
LRF into one single protocol.

      This overloads the registry with data that should not be there.

    * No consideration for multiple Registries.

      If registries are pure LUFs, then there are natural ways to
distribute the namespace over multiple registries: Both in the E.164/ENUM
case and the URI/domains case, the hierarchical DNS can delegate parts of
the global namespace to local registries. The actual call routing is not
affected as the LUF registries do not contain routing data. There is no
need for a registry-registry protocol to synchronize "routes" or "routing
groups".

      If the registries are mixed LUF/LRF ones, then multiple registries
lead to interesting routing problems: Unless every carrier is a customer of
every registry, then achieving worldwide VoIP routing gets tricky. Either:

          o Transit carriers re-announce PIs they learned from one registry
into all other registry they are connected to. That means that the same PI
will appear in each registry multiple times and the registry needs to
decide which path announce with what preference to carriers in need of
transit. Additionally, I don't see how you can prevent routing loops in
this scenario.

          o We invent a registry-registry protocol that avoids these
re-announcements. That just opens another can of worms: will there be a
full mesh between the registries? What kind of routing policies will the
registries implement on behalf of their customers?

    * Routing is a core competence of a carrier.

      I just cannot image the any serious transit carrier will want to
outsource its transit routing algorithm to a foreign party.

      This is not an issue as long as the registry will contain only pure
peering data.

__Summary__

Both working-groups are building a complex solution for a very restricted
special case of the generic VoIP routing problem. This will work only in
tightly restricted setups.

But it will block a clean solution for the underlying problem and will
encourage ugly hacks in the long term.

This is like designing the IBM PC with its 640kB limit while you already
know that this will lead to EMS, XMS, himem.sys and all these kludges once
you want to do more with the design than just run visicalc.

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

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 11 Aug 2009 08:35:17 +0100

Otmar,

Why do you say both WGs are to blame? SPEERMINT does indeed have the
LUF/LRF split, so what do you feel is the problem in SPEERMINT?

Also, perhaps you should post this to the SPEERMINT list too and say
that discussions are taking place on the DRINKS list (to avoid ongoing
cross-posting).

John 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Otmar Lendl
> Sent: 10 August 2009 16:41
> To: PFAUTZ, PENN L, ATTCORP
> Cc: [email-masked]
> reasons for that (see draft-lendl-speermint-background), and 
> I don't expect
> supposed to do "peering" and not "routing". In other words, Speermint
> Speermint documents. This just amounts to "we need to consider these
> scenarios", but not to "here is how you solve them".
> 
> What's not to like?
>       It's an illusion that we can build a system solely for peering

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Tue, 11 Aug 2009 09:12:09 -0400

That's an odd statement.  I take Otmar's input as constructive, not an attempt to assign "blame".

Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Elwell, John
Sent: Tuesday, August 11, 2009 3:35 AM
To: Otmar Lendl; PFAUTZ, PENN L, ATTCORP
Cc: [email-masked]
Subject: Re: [drinks] Comment on today's drinks discussion

Otmar,

John

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 11 Aug 2009 15:03:46 +0100

Yes, I too took it as constructive, but it seemed to suggest both DRINKS
and SPEERMINT had taken a turn in the wrong direction. Whilst it is
clear from his message why he thinks DRINKS has done so, it is not so
clear to me why he thinks SPEERMINT has done so. Sorry about the choice
of word.

John 

> Sent: 11 August 2009 14:12
> To: Elwell, John; Otmar Lendl; PFAUTZ, PENN L, ATTCORP
> Cc: [email-masked]
> That's an odd statement.  I take Otmar's input as 
> constructive, not an attempt to assign "blame".
> 
> Ken
> 
> [mailto:[email-masked]] On Behalf Of Elwell, John
> are not the intended recipient, please contact the sender by 
> reply e-mail and destroy all copies of the original message.
> 
>

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 11 Aug 2009 20:34:13 +0100

> From: Otmar Lendl [mailto:[email-masked]] 
> Sent: 11 August 2009 20:01
> To: Elwell, John
> Cc: [email-masked]
> Elwell, John wrote:
> John,
> I haven't read the speermint docs (or the mailinglist) in a while, and
> missed the last session, too. But a quick glance at
> draft-ietf-speermint-voip-consolidated-usecases-13 shows fundamental
> LUF/LRF missunderstandings in that document. The SED should 
> be the output
> of the LRF and not the LUF.
[JRE] I see - that does indeed appear to be wrong.

John

> *shrug*
> I was mentioned by name in this thread, thus I replied here.
> 
> /ol
> --

---

From: Otmar Lendl <[email-masked]>
Date: Tue, 11 Aug 2009 21:01:18 +0200

John,

LUF/LRF missunderstandings in that document. The SED should be the output

*shrug*

/ol