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

From: "David Schwartz" <[email-masked]>
Date: Wed, 29 Mar 2006 01:18:08 +0200

Hi Reinaldo

I am not sure the goal of SPEERMINT is to recreate L3 peering at L5. The problem being solved is different in that L3 peering is always with a fixed number of neighbors. These are stored as you mention in static routing tables at each node and do not change from call to call. In contrast, L5 peering is not necessarily static (unless you are talking about a federation model). The destination is chosen only when the call is made and may be to a peer that a given service provider/domain administrator/node has never spoken to before. 

Assuming DNS is used to find the peering node, the query is made on a call by call basis. Now clearly, this DNS info can be cached at the originating node but the cache still has a very different nature than that of an L3 routing table.

Policy is an entirely different issue (as is the case in L3) and it is important to separate it out from the routing issue. The draft you mention about pushing policy via DNS is dealing with one out of many possible topologies - namely that of ad hoc federations. There was very little discussion about policy at IETF 65 as the foundations of L5 routing need to be cemented before the higher level policy issues can be addressed.

Cheers,

David

-----Original Message-----
From: Reinaldo Penno [mailto:[email-masked]] 
Sent: ג 28 מרץ 2006 23:34
To: [email-masked]
Subject: [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: "Reinaldo Penno" <[email-masked]>
Date: Tue, 28 Mar 2006 18:48:28 -0500

Hello David,

Thanks for reading my lengthy email. Just to clarify things, I'm not really advocating the recreation of the layer 3 peering model. 

I was raising some questions based on the experience acquired on more than 30 years of layer 3 peering. I understand they are different problems (but they sure also have similarities). 

During these 30 or so years of layer 3 peering and BGP, very similar discussions already happened with just the names changed. "What if a new peer/router comes along?", "Can we perform policy routing on a packet by packet basis?", "Where BGP policies will come from?", "What if I want to filter some packets based on 5-tuple?", etc, etc. You can change the names to SIP, Proxy, DNS, and the questions become very similar.

So, more to your email, although theoretically you can have any number of VoIP peers (just like Layer 3 peers) it _seems_ to me based on interconnection agreements and others, their identities and number will be well known since configurations will need to be made (DNS, Sip Proxies, etc, etc) before hand. So, although a call to a certain service provider domain might never happen, all configurations must be in place for that to happen. Is that a reasonable assumption?

Just like two layer 3 peers might exchange routing tables but never actually see a data packet for a while. 

It begs the question why the two entities exchanging SIP signaling do not exchange policy information themselves through some SIP extension/new protocol/<some name> and the role played by DNS. I'm not advocating this model but it seems a pertinent question. 

Regards,

Reinaldo

> From: David Schwartz [mailto:[email-masked]]
> Sent: Tuesday, March 28, 2006 3:18 PM
> To: Reinaldo Penno; [email-masked]
> Subject: RE: [Speermint] Comments on reqs-and-terminology-01 and policy-
> dds-00(Peerign concepts and others..)
> 
> Hi Reinaldo
> 
> I am not sure the goal of SPEERMINT is to recreate L3 peering at L5. The
> problem being solved is different in that L3 peering is always with a
> fixed number of neighbors. These are stored as you mention in static
> routing tables at each node and do not change from call to call. In
> contrast, L5 peering is not necessarily static (unless you are talking
> about a federation model). The destination is chosen only when the call is
> made and may be to a peer that a given service provider/domain
> administrator/node has never spoken to before.
> 
> Assuming DNS is used to find the peering node, the query is made on a call
> by call basis. Now clearly, this DNS info can be cached at the originating
> node but the cache still has a very different nature than that of an L3
> routing table.
> 
> Policy is an entirely different issue (as is the case in L3) and it is
> important to separate it out from the routing issue. The draft you mention
> about pushing policy via DNS is dealing with one out of many possible
> topologies - namely that of ad hoc federations. There was very little
> discussion about policy at IETF 65 as the foundations of L5 routing need
> to be cemented before the higher level policy issues can be addressed.
> 
> Cheers,
> 
> David
>