Subject: Re: [Speermint] Comments on reqs-and-terminology-01 and policy-dds-00(Peerign concepts and others..)

From: "Stastny Richard" <[email-masked]>
Date: Wed, 29 Mar 2006 00:53:07 +0200

Hi all,
 
Thank you Reinaldo for opening up the discussion on peering and interconnect,
after the shocked quiet period after the meeting ;-)
 
I agree with you that we have to step back (maybe even two steps) after this
Speermint meeting and reconsider what we want to achieve.
 
Lets reconsider what we are talking about:
 
Speermint is primarily about interconnecting sip proxies at L5
the L5 in SIP is a location service
 
two SP have the task to find out for their users (customers) the
IP addresses to allow them to establish a session and finally
exchange IP packets on L3.
 
We also could define this in another way: a SP is giving out
to their customers a public user identity, in SIP also called
an Address-of-Record. Note the term PUBLIC.
 
If I get a public user identity from a SP, I assume to be able to give this
to somebody else and he/she is able to reach me via a public
communications network (note that I do not mention here
the Internet, also a walled garden network such as Vonage
is a public communications network)- Ok they are not giving out AoRs
 
So if I use this public user identity in any other public "network"
accepting SIP URIs (in the definition of Speermint) or with any other 
SP providing services for the public, I assume to be able to reach the
user having this public user identity. And speermint is only talking
about peering or interconnecting with SIP URIs (E.164 numbers
need first to be translated to SIP URIs (AoRs)
 
The originating SP has NO CHOICE other then to Interconnect
on L5 with the termination SP. We can do these games with
"peering", "peering federations", etc. only as long as there
is another choice, e.g. the PSTN for voice calls.
 
The terminating SP has a monopoly (or in EU terms, he
has Significant Market Power (SMP) (which may imply
some remidies, such as the requirement to interconnect!

The terminating SP may reject incoming calls, but only
on behalf (or by order) of the end-user. not on his own.
 
the terminating SP may belong to a federation or even more
then one, but this is only shifting the problem, because then
the SMP (monopoly) moves then to the federation.
 
A federation MAY be used for additional policies such as
ADDITIONAL provision of end-to-end QoS or special peering
(direct links on L3), but IMHO a call set-up via plain SIP may never
be rejected, because of the originator has no other choice.
 
What could (should) be done by Speermint is defining a minimum
set of requirements (profile) which are required to interconnect,
(e.g. TLS, some level of certificates, asserted user identities, etc.)
but if these are met, a terminating SP provider must accept a call
in principle (the end-user may reject it finally, e.g. not accepting calls
from .biz or or from sip:[email-masked] or whatever)
 
I have something similar as the profile between SP and PBX in mind
as created by the SIPForum.
 
If Speermint has achieved this, it may move on to more complicated 
stuff, such as peering policy agreements providing additional SLAs
eg on L3.
 
The either we want to enable a public communications network
(and I cannot imagine something else in IETF) or not. If
not Speermint is out of scope as a whole.
 
regards
 
Richard

________________________________

Von: Reinaldo Penno [mailto:[email-masked]]
Gesendet: Di 28.03.2006 23:34
An: [email-masked]
Betreff: [Speermint] Comments on reqs-and-terminology-01 and policy-dds-00(Peerign concepts and others..)

Hello,

I've been reading "reqs and terminology" and I would like to step back
and ask some questions about some of the definitions.

Peering:
========

In layer 3 peering two routers exchange their routing tables, reach a
steady state, and after that data packets can flow between the two
domains.

Layer 5 peering means, "interconnection of two service providers for the
purposes of SIP signaling".

Making the inevitable comparison with layer 3 peering, there are some
fundamental differences that I'm trying to reconcile.

1) In a traditional (a.k.a. layer 3) peering, both routers exchange all
necessary routing information and enter a steady state. At this point,
no other routes are exchanged and routers concentrate on forwarding
packets.

I know the WG is in the beginning, but it is not clear to me what pieces
are needed for an equivalent functionality. For example:

1) Are the entities exchanging SIP signaling for the purpose of peering
doing so on a _per call_ basis?  Is there going to be some mechanism to
exchange such information in bulk such as in a routing protocol? Maybe
based on domain names or something similar?

2) The draft states that " A
   domain's ingress point can be thought of as the location pointed to
   by the SRV record that resulted from the resolution of the CRD (i.e.,
   a SIP URI)."

So, it seems to me that although the "layer 5 peering" is happening
between the two entities exchanging SIP signaling, the peering point
discovery is a result of a SRV query. But the draft also states that "
SPEERMINT Working Group is focused on the use of such CRD."

Draft peering-policy states that " This documents proposes the use of
DNS entries to publish a SIP proxy's policy for accepting incoming
calls" proposes DNS as a way of exchange polices.

This begs the question of what are the two "peering" entities really
doing besides exchange traditional SIP signaling? It seems the real
_information peering_ (for the lack of a better term) is happening
between DNS servers. All important information related to "peering" is
coming from a DNS server which might as well be on your own domain (if
your exchange DNS information).

In summary, it seems to me the whole architecture is quite a departure
from layer 3 peering where the entities peering are the holders of the
necessary information to allow data packets to flow. Here the entities
peering publish their peering information to third party server which
does the actual "peering" (exchange inter-domain information).

Anyway, the idea of the mail is to try to clarify things. There is much
emphasis on SIP but it seems DNS plays a more central role. Or maybe
some SIP extension will be made to exchange peering policies?

Policies and Independence of lower layers:
==========================================

It seems sections 5.5 and 5.6 are _somewhat_ conflicting. Today BGP
exchange QoS and VPN information, performs discovery, etc. This implies
that BGP indirectly (or directly) knows the capabilities of the
transport layer (thus the name capability negotiation).

So, although the mechanism to exchange the actual policies needs to be
independent of the lower layers, there needs to be a way to input lower
layer information into the devices exchanging the policies. Just like
BGP has filters and priorities based on a myriad of options. So, maybe
the wording should change a little.

As far as 5.6 goes, it seems to me the policies can be quite complex.
The experience of BGP tells us that in the end policies can be huge. So,
if policies are going to be huge, what draft dds-00 states as a
possibility

" If the simple boolean logic and the limited space in the DNS answers
   are insufficient for an application then a type of policy rule URIs
   can be defined which links to policy statements written in a fully
   featured policy description language like SAML [14] or XACML [15]."

will actually going to be the rule. So, this begs the question of DNS is
a good choice to publish peering policies.

Thanks,

Reinaldo

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

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

---

From: Otmar Lendl <[email-masked]>
Date: Wed, 29 Mar 2006 18:54:19 +0200

This is a valuable discussion.

> an Address-of-Record. Note the term PUBLIC.

This is a critical element for the Speermint charter.

Are we dealing with public user identities in the meaning
of "reachable by anybody via the public Internet" or not?

> is a public communications network)- Ok they are not giving out AoRs

What I see right now is that some big service providers

* give customers telephone numbers (as their _public_ identity)
* use SIP AoRs internally.

[The same is true for a lot of corporate PBX systems: Internally they
use SIP but all communication with the outside world is done via the PSTN.]

The drafts I wrote are targetted at that setting. They assume
that we start with zero IP-based interconnection. Calls between
different service providers may be possible over the PSTN,
but universal connectivity based on SIP AoRs is *not* assumed.

I try to offer a path to do better than this 0% IP-based
interconnection. Universal reachability on SIP basis may be
a goal, but not reaching it isn't failure. *Any* SIP-based
interconnection is progress if you start at 0%.

On the other hand, if we're assuming that the SIP AoRs are PUBLIC, 
then I wonder what real world problem Speermint is supposed to solve. 
Basic interconnection is very well specified by the relevant SIP RFCs.
There is hardly any work to do. Maybe some L3 interactions to
enhance QoS. Maybe some SIP profiles.

Maybe we should ask ourselves who will implement the results
of the Speermint WG. Who are our "customers"? What are their assumptions
and what issues need to be addressed so that they will agree to
use our work? And why aren't the current SIP RFCs enough for them?

I'd really appreciate consensus on that question.

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