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

From: "Reinaldo Penno" <[email-masked]>
Date: Tue, 28 Mar 2006 16:34:03 -0500

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

---

From: Otmar Lendl <[email-masked]>
Date: Thu, 30 Mar 2006 11:12:21 +0200

> and ask some questions about some of the definitions.

Good idea. Here is my answer.

> steady state, and after that data packets can flow between the two

I think this definition is too broad: it applies to any BGP connection.

A Layer 3 peering is a shortcut connection established to avoid
sending the traffic via the default upstream networks. Such
a direct connection saves money (upstream is more expensive) and
improves the network performance.

L3 peering is not about reachability per se. For that, one
single interconnect to an upstream networks suffices.

I'll use the term "interconnection" below in a very generic sense,
and not in the one used in the PSTN world. I'm very much open 
to alternative wordings.

So what about:

-----
SIP Peering is the establishement of an alternative communication
path between the SIP elements of two entities (service providers,
corporations, ...) to improve over the service offered by the 
default interconnection. The improvements offered by this new path 
can include (but are not limited to)
  * better QoS
  * cost benefits (e.g. if the default path is billed by minute)
  * additional features (e.g. wideband codecs or IM)
  * abuse handling.

The default interconnection between two parties is out of scope
for the Speermint WG. 
-----

I don't think we should care whether the default interconnection
mechanism is SIP according to RFC3261, the PSTN, SIP via
a transit network, or simply no default interconnection at all.

All we need to focus on here in Speermint is to define
a framework which can be used to establish more direct and thus
better crosslinks between two SIP service providers.

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