Subject: [Speermint] [wg-business] Updating Milestones

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 16 Feb 2007 16:43:05 -0500

All - 

We have been spending a lot of time thinking about our current
milestones and, philosophically, about how documents and work flows
through the group.  I am a bit of a visual thinker so I created the 3
variations of document flows to facilitate discussion with our ADs and
other stakeholders.  Those different flows are attached, for your
information.

I believe we have concluded this now and we are close to an update of
our milestones (see below).  In addition, if you open those flow charts,
we have concluded that Document Flow v1-C will satisfy the various
interested parties in SPEERMINT and will be using that as a guide.

A few key points:

* This recognizes that VoIP (TN-based URIs and voice apps) and IM
(username-based URIs and various apps) have very different use cases and
requirements.  Continuing to try to jam them together is
counter-productive.  Separating them will accelerate each track of work.

* This recognizes that it is not for us to decide if TN or name-based
URIs win/lose in the end.  We work to accomodate applications that use
both; the market and implementers will ultimately decide upon success or
failure.

* Many of the pieces of the infrastructure used converge in the
architecture document, though there will be important differences in
some cases.  There is enough similarity and potential for shared
elements that one overall architecture seems to hold some promise.

* Out of that flows application / implementation-specific docs, on
message flows, DNS/NAPTR, etc.  These should very specifically tell an
implementer what they need to do.

* There are 3 likely stages or levels of deployment that should be
accomodated: DIRECT, FEDERATED, and OPEN (e.g., over the open Internet).
Depending upon the implementer, the maturity of their
app/business/users/regulations/etc., one may make sense.  In general,
the lifecycle is Direct --> Federated --> Open.  It is impossible for us
to predict or guide when the market or implementers will go to each
stage; we should try to describe how to do each and let implementers
figure out the rest.  This also recognizes that this is not a battle of
direct vs. federated vs. open, as each has a place and a role.

--> CURRENT Goals and Milestones:
Jul 2006	  	Submit SPEERMINT terminology I-D (Informational)

Sep 2006	  	Submit I-D defining the SPEERMINT routing
architecture (Informational) 
Dec 2006	  	Submit I-D defining the message flows associated
with the SPEERMINT routing architecture (Informational) 
Jan 2007	  	Submit I-D on the use of DNS SRV and NAPTR
records as specified by RFC 3263 (BCP) 
Mar 2007	  	Submit I-D on the minimum set of requirements
for SIP-based VoIP interconnection (BCP) 
Jul 2007	  	Submit I-D specifying the use of strong
identities in session peering and supporting the establishment and
exchange of trust between domains (BCP) 
Jul 2007	  	Submit I-D(s) on use cases (BCP) 
Jul 2007	  	Propose re-chartering for any additional
efforts/considerations, or propose conclusion of working group
(following approval of last documents) 

--> PROPOSED New Goals and Milestones:
Apr 2007	Submit SPEERMINT terminology I-D (Informational)
Aug 2007	Submit SPEERMINT VoIP-specific use cases I-D
(Informational)
Aug 2007	Submit SPEERMINT IM-specific use cases I-D
(Informational)
Jan 2008	Submit SPEERMINT architecture I-D (Informational)
Feb 2008	Submit SPEERMINT message flows I-D (Informational)
Feb 2008	Submit SPEERMINT DNS SRV and NAPTR use I-D (BCP)
Feb 2008	Submit SPEERMINT minimum requirements for SIP-based VoIP
interconnection. (BCP)
Mar 2008	Propose re-chartering for any additional
efforts/considerations, or propose conclusion of working group
(following approval of last documents)

Regards
Jason
_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint

---

From: Daryl Malas <[email-masked]>
Date: Fri, 16 Feb 2007 17:50:01 -0700

This makes sense to me.  Thanks for working to put this together.

--Daryl

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 19 Feb 2007 18:18:12 +0100

Jason,

thanks for the update and the work two put into this.

> counter-productive.  Separating them will accelerate each track of work.

Agreed.

> URIs win/lose in the end.  We work to accommodate applications that use

Agreed as well.

> implementer what they need to do.

I'm a bit worried about the classification of all the work as
"Informational" or "BCP".

That kind of implies that all the building blocks for the speermint
solution are already there and just need to be assembled to implement
all those use cases in real life.

In various areas, that's certainly true: There is no need to re-invent
SIP, TLS, Identity:, ENUM. There are other aspects where I think
some protocol work is needed. These include:

* Multi-hop routing.

  IMHO The whole premise of speermint is the fact that people do not
  run open SIP servers and thus RFC3263 alone won't get servers to
  talk to each other.

  Just look at the Enterprise Peering use-cases in the new draft:
  Multi-hop peerings are featured prominently there. Right now, I don't
  see which existing protocols could be used to select the correct set
  of transit carriers which can act as the bridge between source and
  destination enterprise.

* Routing based on numbers

  Right now, I see only ENUM and TRIP as IETF standards in that area.
  TRIP hasn't seen any deployment, and ENUM is a simple mapping, but
  not a routing protocol.

  We run into the same issue as before: classic ENUM + RFC3263
  won't cut it in a world, where SIP servers don't work like
  email servers.

I really hope that the IETF will engineer a solution to this issues and
not concede this space to proprietary third party service providers.

/ol 
-- 
< Otmar Lendl ([email-masked]) | nic.at Systems Engineer >

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 20 Feb 2007 16:28:48 -0500

> That kind of implies that all the building blocks for the 
> speermint solution are already there and just need to be 
> assembled to implement all those use cases in real life.
<snip>
> I really hope that the IETF will engineer a solution to this 
> issues and not concede this space to proprietary third party 
> service providers.

First off, the major point we wanted to convey was more that the main
documents that flow from the work will help implementers in a concrete
way.  We can decide with the ADs how various documents are classified
once they start to mature.  

Also, I do not necessarily preclude any new protocol work, though our
ADs have counseled to be careful in this as that work may rightly fall
into other WGs.  In the end, I would say let's cross that bridge when we
come to it, so to speak.  

If you have some suggestions on how multi-hop routing and routing based
on numbers should occur that is not fully addressed elsewhere, I
encourage you to start up some threads on the mailing list here.  I
suspect other folks may be experiencing the same issues you cite, but
the only way to tell is to start up discussion.  (I may recommend a
separate thread / email for each item so we can segment discussion
topics.)

Thanks
Jason

---

From: Otmar Lendl <[email-masked]>
Date: Wed, 21 Feb 2007 22:55:19 +0100

> into other WGs.  In the end, I would say let's cross that bridge when we

The signs are on the wall, or to be more precise, in the requirements
draft. For example:

   o  Variability of the Call Address Data:
      A terminating VSP/ASP or user SHOULD be able to indicate its
      domain ingress points (Signaling Path Border Element(s)) based on
      the identity of the originating VSP/ASP or user.
      The mechanisms recommended for the use and resolution of the call
      addressing data SHOULD allow for variability or customization of
      the response(s) depending on various elements, such as the
      identity of the originating or terminating user or user domain.

The current proposal (draft-ietf-speermint-srv-naptr-use-01) just
rehashes RFC3263 which specifies an algorithm which is independent
of the identity of the originating network. It's just a function of
(destination domain, DNS records) and thus cannot take into account who
is asking the DNS (unless you propose to play with fire (i.e. split DNS)).

> encourage you to start up some threads on the mailing list here. 

There is some discussion on domain based multihop routing in
http://tools.ietf.org/html/draft-lendl-speermint-federations-03 .

I'll elaborate on the need for this in a future mail.

/ol

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 23 Feb 2007 15:39:23 -0500

So basically, you want the ENUM server to give a different URI to a
querying party, depending upon who that party is?

For example, you are network1.  If network2 queries your ENUM server for
a URI lookup, you want them to go to border-element-1.  But if network3
queries you, you want them to go to border-element-2.

Yes?

Jason

PS - Which section of
http://tools.ietf.org/html/draft-lendl-speermint-federations-03 should
we refer people to read as background? (4.4.3?)

> -----Original Message-----
> From: Otmar Lendl [mailto:[email-masked]] 
> Sent: Wednesday, February 21, 2007 4:55 PM
> To: [email-masked]
> Subject: [Speermint] Selecting the right ingress point
> 
> On 2007/02/20 22:02, "Livingood, Jason" 
> <[email-masked]> wrote:
> > 
> > into other WGs.  In the end, I would say let's cross that 
> bridge when 
> > we come to it, so to speak.
> 
> The signs are on the wall, or to be more precise, in the 
> requirements draft. For example:
> 
> The current proposal (draft-ietf-speermint-srv-naptr-use-01) 
> just rehashes RFC3263 which specifies an algorithm which is 
> independent of the identity of the originating network. It's 
> just a function of (destination domain, DNS records) and thus 
> cannot take into account who is asking the DNS (unless you 
> propose to play with fire (i.e. split DNS)).
> 
> > If you have some suggestions on how multi-hop routing and routing 
> > based on numbers should occur that is not fully addressed 
> elsewhere, I

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 23 Feb 2007 15:49:19 -0500

> From: Livingood, Jason [mailto:[email-masked]]
> Sent: Friday, February 23, 2007 3:39 PM
> To: Otmar Lendl; [email-masked]
> Subject: RE: [Speermint] Selecting the right ingress point
> 

Right and just how would you validate whom the requestor is  .. VPN's
subnets... 

gee Otmar you've just made a fantastic argument for private ENUM.

---

From: "Stastny Richard" <[email-masked]>
Date: Fri, 23 Feb 2007 22:59:02 +0100

>gee Otmar you've just made a fantastic argument for private ENUM
 
?
 
I set up a private ENUM server for any VSP I peer with?

Richard

________________________________

Von: Richard Shockey [mailto:[email-masked]]
Gesendet: Fr 23.02.2007 21:49
An: 'Livingood, Jason'; [email-masked]
Betreff: RE: [Speermint] Selecting the right ingress point

---

From: Otmar Lendl <[email-masked]>
Date: Fri, 23 Feb 2007 23:42:36 +0100

> querying party, depending upon who that party is?

I was talking about pure SIP, no ENUM involved.

> queries you, you want them to go to border-element-2.

Generally speaking you can make any of the mapping steps from 
telephone number to IP address sensitive to the querying network:

1) Give different answers to ENUM queries

2) Give different answers to RFC 3263 NAPTR queries

3) Give different answers to SRV queries

4) Give different answers to A queries

5) Slightly modify 3263 to ask different questions depending on
   who's asking and/or which federation is used

6) Junk RFC 3263 and use other means to map SIP URI to
   an ingress point.

7) Use something other than plain ENUM to do the number->URI mapping

> Yes?

What my code implements is option 5). e.g. with my OpenSer Domainpolicy
code a federation can modify the RFC3263 rules to prefix the domain with
e.g. the federation name before doing the NAPTR/SRV lookup.

Other options are to query a private DNS tree for these records.

As I built my scheme in a way to work both for number-based dialing
*and* URI based dialing, it didn't make sense to fiddle with the ENUM
lookup as that cannot help me with URI-based calls.

> we refer people to read as background? (4.4.3?)

My draft isn't very specific on what federations could use to get
this source-dependent ingress points. A bit is in the examples:

   o  Peering fabric based on SIP: A SIP hub acts as a forwarding proxy
      between participants.  Intra-federation calls are to be routed
      through the SIP hub.

in that case, no NAPTR/SRV/A lookups are performed for intra-federation
calls: all VSPs just route to the central SIP hub.

You can find more specifics in the documentation to my code, see
http://openser.org/docs/modules/1.2.x/domainpolicy.html.

Klaus' HOWTO is contains more examples, but it refers to a slightly
older versions of the code. You can read it here:
http://www.enum.at/typo3conf/ext/nf_downloads/pi1/passdownload.php?downloaddata=46

My slides from the Philly interim meeting contain examples as well,
see http://www.enum.at/ietf/20060918-speermint-interim.ppt
(Slides 28ff)

/ol

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 26 Feb 2007 12:59:33 +0100

Two clarifications:

> 7) Use something other than plain ENUM to do the number->URI mapping

All these options are relevant for call-routing *within* a federation.
Thus, different federations are likely to employ different methods.

e.g. the typical Assisted Peering federation (Think xconnect) uses 
option 6: bounce all calls to a central SIP proxy of the federation
(TN are trivially encoded into usernames), and that proxy answers
per 3XX code with the real destination's ingress point, or just forwards
to the call itself.

Alternatively, a federation based on SIP over TLS, secured via certs
from a central CA using the public internet does not need to deviate
from RFC 3263 rules.

I consider it thus to be important that this WG recognizes:

* RFC 3263 is not appropriate for all types of federations

* Some federations will have to find ways to make the ingress-point
  sender-dependent.

  - Speermint should offer some examples on how this can be arranged

  - There is no need that speermint elevates one such scheme into
    "This is the only way you should be doing it" status.

On the other hand, the question "How does a VSP select the right
federation via which to route a call?" needs a single answer.

---------

Summary:

* The Speermint work can be divided into two area:

  1) Intra-federation  

	"How does member VSP-A send an INVITE to fellow member VSP-B?"

  2) Overall multi-hop routing:

  	"Which peer in which federaton is my best next hop for
	my call to TN/URI?"

* There is no need (or even point) in selecting a single solution for 1).

* It is important to agree on a single algorithm for 2).

My drafts (draft-lendl-speermint-federations et al) address only 2). 
They provide a few hints and examples of 1), but that is purely for
illustrative purposes. My OpenSer code does implement a few schemes
for 1).

/ol