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

From: "Medhavi Bhatia" <[email-masked]>
Date: Tue, 28 Mar 2006 19:56:40 -0500

Hi Richard,

> 
> 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.

I think this is the wrong assumption given P2P SIP. Why can't the user
have a unique public user identity and it not be linked to the SP at all
(The SP may not be a VoIP SP).

> 
> 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 think we should use this to set the minimum scope given the amount of
confusion in the WG at this point. This can actually be done and I
believe will be useful.

-Medhavi.

> 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
> 
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.385 / Virus Database: 268.3.1/292 - Release Date:
3/24/2006

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

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Tue, 28 Mar 2006 20:12:59 -0500

> 
> 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.

I think peering in L3 must be basic, given how fundamental L3 is to the internet. For SIP, TRIP provides functionality similar to BGP (only for phone numbers though, I think).

In my opinion, SIP peering ought to follow the email model. Once location is done and basic requirements are satisfied at the SIP layer (like identity etc), the call should be routable. As Richard said in the earlier email, the destination SP may still reject or challenge the call if it lacks either the basic requirements we agree to in the WG or some extra requirements specific to the termination SP (Core-T in my ID). The challenge is that in some cases there are going to be IXPs (Interconnects) which sit in the middle due to commercial or regulatory reasons. The location of an IXP, the provisioning of this IXP and the Core-T SP are the architectural problems which this WG needs to solve as well.

-Medhavi.

> 
> Regards,
> 
> Reinaldo
> 
> > -----Original Message-----
> > 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
> >
> > -----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,
> >
> > Layer 5 peering means, "interconnection of two service providers for the
> > 1) In a traditional (a.k.a. layer 3) peering, both routers exchange all
> > I know the WG is in the beginning, but it is not clear to me what pieces
> > 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
> >    by the SRV record that resulted from the resolution of the CRD (i.e.,
> >    a SIP URI)."
> >
> > Anyway, the idea of the mail is to try to clarify things. There is much
> > exchange QoS and VPN information, performs discovery, etc. This implies
> > independent of the lower layers, there needs to be a way to input lower
> > The experience of BGP tells us that in the end policies can be huge. So,
> > will actually going to be the rule. So, this begs the question of DNS is
> Version: 7.1.385 / Virus Database: 268.3.1/292 - Release Date: 3/24/2006
>

---

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

Hello,

I tend to agree that the email model sounds attractive except the delay and business requirements of email and VoIP are quire different.

Email is not delay sensitive, does not require any type of prioritization and is not charged (or at least it wasn't).

VoIP is exactly the opposite. VoIP (signaling and media) are delay sensitive, need prioritization and will be billed.  

I believe a call to a public number is (or should) always going to be routable. I guess my main question is: is the general belief that VoIP providers will just configure their proxy servers to talk to each other in an email type model? No business agreements similar to PSTN/Wireless, no charging, no extra billing for "roaming", etc?  

My reply to David's email was more to the idea that you can install a proxy server somewhere, point the "MX" to the next upstream "proxy server" and be done with it? As VoIP takes off wouldn't some basic regulatory issues, numbering schemes and others prevent such behavior? 

These are not rhetoric questions; I really do not know the answer.

Regards,

Reinaldo

> From: Medhavi Bhatia [mailto:[email-masked]]
> Sent: Tuesday, March 28, 2006 5:13 PM
> To: Reinaldo Penno; David Schwartz; [email-masked]
> Subject: RE: [Speermint] Comments on reqs-and-terminology-01 andpolicy-
> I think peering in L3 must be basic, given how fundamental L3 is to the
> internet. For SIP, TRIP provides functionality similar to BGP (only for
> phone numbers though, I think).
> 
> In my opinion, SIP peering ought to follow the email model. Once location
> is done and basic requirements are satisfied at the SIP layer (like
> identity etc), the call should be routable. As Richard said in the earlier
> email, the destination SP may still reject or challenge the call if it
> lacks either the basic requirements we agree to in the WG or some extra
> requirements specific to the termination SP (Core-T in my ID). The
> challenge is that in some cases there are going to be IXPs (Interconnects)
> which sit in the middle due to commercial or regulatory reasons. The
> location of an IXP, the provisioning of this IXP and the Core-T SP are the
> architectural problems which this WG needs to solve as well.
> 
> -Medhavi.
> 
> >
> > Regards,
> >
> > Reinaldo
> >

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Tue, 28 Mar 2006 21:27:30 -0500

Hi Reinaldo,

> Sent: Tuesday, March 28, 2006 8:31 PM
> To: Medhavi Bhatia; David Schwartz; [email-masked]
> Subject: RE: [Speermint] Comments on reqs-and-terminology-01 andpolicy-dds-00(Peerign
> concepts and others..)
> 
> Hello,
> 
> I tend to agree that the email model sounds attractive except the delay and business
> requirements of email and VoIP are quire different.
> 

Good point. What we need is to separate the problem of peering into at least two parts: terminating the call and the traffic itself (data part). The email model applies only to the termination part.

> I believe a call to a public number is (or should) always going to be routable. I guess my
> main question is: is the general belief that VoIP providers will just configure their proxy
> servers to talk to each other in an email type model? No business agreements similar to
> PSTN/Wireless, no charging, no extra billing for "roaming", etc?
> 

I agree those are issues. It would be good if we can work out something which is generic (compared to IMS/PSTN specific). Maybe they are out of scope since we are dealing with protocol and architecture issues in the WG. The only aspect billing and roaming affect is that if all technical requirements (e.g the ones this WG specifies) are satisfied, the peer could still reject traffic (w/o consulting the destination user, in Richard's terms) if the commercial relationship does not exist. I think this is what hampers connectivity today. All these commercial relationships exist because SPs want to be layer 5 aware (they cannot seem to find a way to evolve their business models otherwise... :), where only the origination SP (Core-O) and Core-T need to have a commercial relationship. The roaming aspect again may be quite artificial and could be questionable going forward...  Just my personal comments.

-Medhavi.

> My reply to David's email was more to the idea that you can install a proxy server
> somewhere, point the "MX" to the next upstream "proxy server" and be done with it? As
> VoIP takes off wouldn't some basic regulatory issues, numbering schemes and others
> prevent such behavior?
>