[drinks] Some comments on the use-cases draft

[Otmar Lendl <[e-mail]>]

Richard wanted some feedback, so here it comes.

This document it a _lot_ better than -01. Much more consistent.

Overall impressions:

* This is a telco design. Basic bell-head thinking with only some marginal
sprinkling of Internet ideas. This is a document which describes how one
might carry over the telco provisioning, interconnection and call routing
approaches to the VoIP world.

All fine and good, but to be provocative: why is this an IETF WG document
and not an ITU-T, OASIS or 3GPP paper? The role model, the actors and a
most use-cases are almost straight from the PSTN playbook.

* This is way too ambitious on one hand. Defining all this in a single
protocol and implementing the registry which actually does all these things
is a herculean task.

Layering, folks. Layering.

Divide the problem into discrete, clearly separated sub-problems (see the
speermint LUF/LRF split for a good one) and the complexity can be brought
under control.

* This is way too conservative on the other hand. There is little dynamic
routing. There is no integration of enterprise VoIP routing with carrier
routing. There no possibility of ad-hoc peering.

Okay, some specifics:

>   SED Record:   A SED Record contains much of the session establishment
>      data or a 'redirect' to another registry where the session
>      establishment data can be discovered.  SED Records types supported
>      are NAPTRs, CNAME, DNAME, and NS Records.

What about TLS parameters, Source IP addresses of SBEs, Codec constraints,
SIP profiles, ...

This is far too DNS focussed.

>   SED is typically created by the terminating SSP and consumed by the
>   originating SSP.

Careful here: in the case of multi-hop routing, the SED towards the next
hop are relevant, and these may have little to do with whatever the
terminating SSP has created. See 4.2.2. of the speermint terminology draft.

>    For scalability reasons SED is rarely exchanged
>   directly between the intended parties.  Instead, it is exchanged via
>   intermediate systems - termed Registries within this document.  Such
>   registries receive SED via provisioning transactions from other SSPs,
>   and then distribute the received data into Local Data Repositories.

This is true for anything dealing with TNs. Once these are mapped to
something amenable to aggregation, this argument falls completely down.

We have a serious mistake in the base assumptions here. If we do proper
layering, then the routing information does *not* need these intermediate
registries. The registries are only needed for the TN -> Destination-Group
mapping.

Yes, that's the way it has been done in the PSTN and thus it would be easy
to integrate VoIP into the same provisioning processes.

That's one of the fundamental design question: do we design an incremental
update to the way carriers have been operating, or do we design an addition
to the IETF SIP world which enables scalable multihop routing based on TNs?

These are two very different goals.

----

>   o  Registries are the authoritative source for provisioned session
>      establishment data (SED) and related information.

Eeek.

SED includes what the next hop is. In a dynamic network, this can change
quickly as SBEs or links fail, congestion makes paths unavailable or some
business decisions make a different path more attractive.

I cannot fathom that

* these real-time routing information is exchanged via the registry,

* carriers outsource the business decision part of the call routing
  algorithm to third parties.

----

>   o  Aggregation of public Identifiers: The initial input "key" to a
>      SED lookup is a public identifier.  Since many public identifiers
>      will share similar (or identical) destinations, and hence return
>      similar (or identical) SED, provisioning the same set of SED for
>      millions of public identifiers is inefficient, especially in cases
>      where the SED needs to be modified.  Therefore, an aggregation
>      mechanism to "group" public identifiers is proposed.  This
>      aggregation is called a "destination group".

This very good.

(and I'm tempted to say that this is all the registries should handle.
Everything else can be done bi-laterally.)

----

Minor nit: please define the acronyms RN and TN. The latter is trivial (or
not, once you leave the E.164 world), but the former might have country-
specific meanings.

----

>    -  A Public Identity is associated with zero or more SED Records

uhh, please don't go there.

----

The actual use-cases aren't that exciting for me, as the overall
architecture decisions I criticize are not a consequence of the use-cases,
but rather seem to come from a "that's the way we do things around here"
argument.

That's a bit thin.

/ol
-- 
// Otmar Lendl <[e-mail]>, T: [phone] - 33, F: - 933 //