Some comments on draft-ietf-speermint-architecture-00.txt

Here are some comments on the architecture draft. All in all a good start and
I'm confident that we can massage it into shape.

*inline*

>                                      
>                      SPEERMINT Peering Architecture 
>                   draft-ietf-speermint-architecture-00 

>2. Network Context 
>
>   Figure 1 shows an example network context. Two SIP providers can form 
>   a Layer 5 peer over either the public Internet or private Layer 3 
>   networks. In addition, two or more providers may form a SIP (Layer 5) 
>   federation [1][9] on either the public Internet or private Layer 3 
>   networks. 

These scenarios are good.

>    
>
>                          +------------------+ 
>                          |     Public       |            
>                          | Peering Function | 
>                          |       or         | 
>                          |     Public       | 
>                          |Federation Function|                           
>                          +------------------+                             
>                                   | 

The diagram doesn't show that any service provider can be 
connected to more than use of the networks. (e.g. the public
internet and two private service provider networks)

That's hard to do in ascii graphics, but some statement to
that effect could be helpful.

>
>3. Procedures 
>
>   This document assumes that a call from an end user in the initiating 
>   peer goes through the following steps to establish a call to an end 
>   user in the receiving peer:  
>
>                 . the analysis of a target address, 

A one-line summary of the first paragraph of 5.1.1 is needed here.
We need to provide the exit for intra-VSP calls.

>                 . the discovery of the receiving peering point 
>                    address, 
>
>                 . the enforcement of authentication and other policy, 
>
>                 . the discovery of end user address,  

I don't see why that is an issue at all: The SIP messages will be
sent to the peering partner's SF, and we will learn from the SDP
where to send the RTP stream to. That may well be a media-gw at
the receiving peer. 

>
>                 . the routing of SIP messages, 
>
>                 . the session establishment,  
>
>                 . the transfer of media, 
>
>                 . and the session termination.  
>
>4. Reference SPEERMINT Architecture 
>
>   Figure 2 depicts the SPEERMINT reference architecture and logical 
>   functions that form the peering between two SIP service providers I 
>   and R, where I is the Initiating peer and R is the Receiving peer. 
>
>    
>                                     +----+ 
>                                     | LF | 
>                          -------    +----+     ------- 
>                         /       \    |  |     /       \ 
>                        |        LF---+  +---LF         | 
>                        |         |           |         | 
>                        |        PF-----------PF        | 
>                        |         |           |         | 
>                        |   SIP  SF-----------SF  SIP   |         
>                        | Service |           | Service |    
>                        |Provider MF---------MF Provider| 
>                        |    I    |           |    R    | 
>                        |         |           |         | 
>                        |         |           |         | 
>                         \       /             \       / 
>                          -------               ------- 

In terms of terminology, shouldn't we perhaps use a different name for
external LF box?

> 
>                Figure 2: Reference SPEERMINT Architecture 
>
>   The procedures presented in Chapter 3 are implemented by a set of 
>   peering functions:  
>
>   o  Location Function (LF): Purpose is to develop call routing data 
>      (CRD) by discovering the Signaling Function (SF), Policy Function 
>      (PF), and end user's reachable host (IP address and port). 

see more below

[...]

>5.1. The Location Function (LF) of an Initiating Provider 
>
>   Purpose is to develop call routing data (CRD) [1] by discovering the 
>   Signaling Function (SF), Policy Function (PF), and end user's 
>   reachable host (IP address and host). The LF of an Initiating 

Once again: I don't understand why it is neccessary to discover the
end user's IP address. It's not even given that the end-user is using
a VoIP phone at all. All we know is that the peering interfaces uses
SIP. There could be a media-conversion to GSM, POTS or whatever inside
the destination network.

>   provider analyzes target address and discovers the next hop 
>   signaling function (SF) in a peering relationship using DNS, SIP 
>   Redirect Server, or a functional equivalent database.   

If there is a Policy Function (PF) active in the setup, then the
LF can't determine the correct next hop information without information
collected by the PF, as the PF knows about the availability of peers,
congestion status, route announcements, and access controls.

IMHO we can't have two seperate, disjoint steps like

	. the discovery of the receiving peering point address, 
	. the enforcement of authentication and other policy, 

where the first is done only by the LF and the second one only by the PF.

Information from the PF is essential to find the right next hop.

>
>5.1.5. SIP DNS Resolution 
>
>   Once a sip: or sips: in an external domain is selected as the target, 
>   the initiating peer uses the procedures described in [RFC3263] 
>   Section 4. To summarize the RFC 3263 procedure: unless these are 
>   explicitly encoded in the target URI, a transport is chosen using 
>   NAPTR records, a port is chosen using SRV records, and an address is 
>   chosen using A or AAAA records.  Note that these are queries of 
>   records in the global DNS. 
>

The PF must be able to override the default RFC 3263 procedure. That may
be because of learned routes (via SUBSCRIBE), or based on federation
announcements.

>
>5.2. The Location Function (LF) of a Receiving Provider 
>
>5.2.1. Publish ENUM records 
>
>   The receiving peer SHOULD participate by publishing "E2U+sip" and 
>   "E2U+pstn" records with sip: or sips: URIs wherever a public carrier 
>   ENUM root is available.  This assumes that the receiving peer wants 
>   to peer by default.  Even when the receiving peer does not want to 
>   accept traffic from specific initiating peers, it MAY still reject 
>   requests on a case-by-case basis. 
>
>5.2.2. Publish SIP DNS records 
>
>   To receive peer requests, the receiving peer MUST insure that it   
>   publishes appropriate NAPTR, SRV, and address (A and/or AAAA) records    
>   in the global DNS that resolve an appropriate transport, port, and   
>   address to a relevant SIP server.   

The problem with the default RFC 3263 approach is, that the receiving peer
has no reasonable way of announcing different ingress points to different
peers. If a VSP is connected to various private networks, a single set
of NAPTR/SRV/A records just won't cut it.

>5.3. Policy Function (PF) 
>
>   Policy function is optional. The purpose of policy function is to 
>   perform authentication and to exchange peering policy capabilities to 
>   be used by the signaling function. 

I think the draft-lendl-speermint-federations-02 ideas fit in very nicely
into this PF.

/ol
--

-- 
< Otmar Lendl (lendl@...) | nic.at Systems Engineer >