Subject: [Speermint] comments on Peering Architecture Draft

From: Klaus Darilion <[email-masked]>
Date: Fri, 21 Jul 2006 13:54:34 +0200

Hi Sohel!

Sorry for reviewing the draft that late, but I was on holidays.

> 2. Network Context
> 
> Figure 1 shows an example network context. Two or more providers on 
> either the public Internet or private Layer 3 networks may form a SIP
>  (Layer 5) federation.  The public or private peering location server
>  function enables discovery of federations and all provider peering 
> points.  Subsequent exchanges with those provider peering points will
>  enable discover of policy and additional signaling and media peering

You use the term federation 2 times although it is described later. I
would put the terminology first.

I'm not happy with the term "peering location server". It sounds like a
dedicated server for location lookup, maybe a dedicated protocol?
I would use the term "peering location service" instead, as it is more
general. E.g. when using ENUM we have DNS servers, and the "peering
location service" consists of the ENUM client together with the name
servers. Thus, also figure 1 would have to be updated.

You further say that during exchanges with the PEERING POINTS the policy 
will discovered. That is not always the case. The policy can be 
discoverd in several ways, e.g. in DNS like in Otmar's draft, or with a 
dedicated protocol with dedicated policy servers (!=peering points) or 
through local configuration.

> [...]
> 
> o  Service Provider to Service Provider across a private internet
> 
> Note also that the nature of the Service Provider is intentionally 
> ambiguous, so it encompasses both VoIP SP and other Application SP.

IMO we should talk about VOIP and Multimedia Service PRoviders. If the 
service provider may have also other services (layer 3, web services, 
email ...), those Application's are out of scope. Thus they should not 
be referenced and we should speak clearly about the VoIP&Multimedia 
parts of the service provider's services.

> Next Hop:
> 
> A next hop may be a direct peer or a transit peer.

So, what is a peer? I would describe the next hop as the host, to which 
the SIP signaling will be sent. The host which has the IP address which 
was resolved with the procedures in RFC3263.

> 3. Reference Peering Architecture 
[...]
>    A real-time application (Voice and Multimedia) IP Service provider 
>    interconnects with other real-time application (Voice and Multimedia) 
>    IP Service providers through a set of peering interface functions 
>    which are discussed next. 

What about the enterprises? Maybe we should add a paragraph which 
describes that all the functionalities are identical for enterprises and 
service providers, thus using only the term "service provider" for 
simplicity.

> 4. Peering Interface Functions 
[...]
> 
>    o  Signaling Function (SF):  Purpose is to enable the discovery of 
>       endpoints and assist in discovery and exchange of parameters to be 
>       used with the MF peering point. (Section 4.3) 

What do you mean by discovery of endpoints? RFC3263 (then I would agree) 
or discovering the URI which will be used as entry point into RFC3263? 
In either cases it should be more clearly.

As we have stated we will use SIP for signaling, why not say clearly 
that the SF is the session signaling with SIP?

> 
>    o  Media Function (MF):  Purpose is to enable the interconnection of 
>       media paths between endpoints. (Section 4.4) 
> 
>    o  QoS Function (QF):  Purpose is to negotiate and reserve bandwidth 
>       resources, as well as police and provide measurements for media 
>       paths. (Section 4.5) 
> 
>    o  Application Function (AF):  TBD (Section 4.5) 

Is there really an AF? If there is an application, IMO it is the 
service, which uses the previously defined planes, so its not a plane 
itself.

>    SIP security, privacy and encryption: The SF may support Security 
>    functions to provide authentication, privacy (encryption) and message 
>    integrity functions. These functions may be provided by using IPSec 
>    or TLS.  

or S/MIME or DTLS or whatever will come - no restrictions. -->
"These functions may be provided by using for example IPSec or TLS."

> 5. Call Control and Media Control Deployment Options 
> 
>    The peering functions can either be deployed along the following two 
>    dimensions depending upon how the SF and the MF along with IP 
>    functions are implemented: 
> 
>    Composed or Decomposed:  Addresses the question whether the media 
>    paths must flow through the same physical and geographic nodes as the 
>    call signaling, 

What about dedicated host for SIP and RTP (like provider A in figure 3) 
- its not a single physical device, but a single logical unit (IMO still 
composed). IMO Decomposed is where the SF has no interaction with the MF 
- e.g. RTP is directly between the SIP phones.

>    Centralized or Distributed:  Addresses the question whether the 
>    logical and physical peering points are in one geographical location 
>    or distributed to multiple physical locations on the service provider 
>    network. 

What is if a provider has several ingress points on the same 
geographical location? IMO this is still distributed. May it can be 
formulated:
   central: a single peering point visible to other peers(it may be a 
load balancer or anycast IP address which distributes the traffic to 
proxies (the proxies are invisible to the outside))
   decentral: multiple peering points visible to the other peers (e.g. 
multiple SRV records, or multiple A records ...)

>    In a composed model, SF, and MF functions are implemented in one 
>    entity. 

What is an entity - maybe we can say "...in a single logical border 
element...". In your figure, where

> 
>  
>                   Provider A                        Provider B 
>                   ----------   .               .   ----------            
>                  /          \  .               .  /          \ 
>                 |            | .       _       . |            | 
>                 |       +----+ .     /   \_    . +----+       | 
>                 |       | SF |<-----/     \------| SF |       | 
>                 |  e.g. +-+--+ .   /Transit\   . |    |       | 
>                 |  MGCP-> | |  .  /   IP    \  . |    |       | 
>                 |       +-+--+ .  \ Provider|  . |    |       | 
>                 |       | MF |<~~~~\(Option)|~~~~| MF |       | 
>                 |       +----+ .    \      /   . +----+       | 
>                 |            | .     \__ _/    . |            | 
>                  \_________ /  .               .  \________ _/ 
>                   ----------                       ---------- 
>                     
>              --- Signal (SIP)    
>              ~~~ Bearer (RTP/IP) 
>              ... Scope of peering 
>   
>                  Figure 3: Decomposed v. Composed Peering 
> 
>  
>  
> khan                  Expires December 17, 2006                [Page 9] 
> 
> Internet-Draft     draft-khan-ip-serv-peer-arch-03            June 2006 
>     
> 
>    The advantage of composed peering architecture is that one-device 
>    solves all peering issues. Disadvantage examples of this architecture 
>    are single point failure, bottle neck, and complex scalability. 
> 
>    In a decomposed model, SF and MF are implemented in separate 
>    entities. Signaling functions are implemented in a proxy and media 
>    functions are implemented in another device.  The scaling of 
>    signaling versus scaling of media may differ between applications.  
>    Decomposing allows each to follow a separate migration path.

As said above, I would not differ between a single or multiple physical 
devices, but a single or multiple logical devices.

>    This model allows the implementation of M:N model where one SF is 
>    associated with multiple peering routers and one peering router is 

What is a "peering router" L5? L3? Do we need that device?

>    associated with multiple peering proxies. Generally, a vertical 
>    protocol such as MGCP associates the relationship between a peering 
>    proxy and a peering router. This architecture reduces the potential 
>    of single point failure. This architecture, allows separation of the 
>    policy decision point and the policy enforcement point. An example of 
>    disadvantages is the scaling complexity because of the M:N 
>    relationship and latency due to the vertical control messages between 
>    entities.  

Maybe some of this concerns were already discussed on the list - but I 
still have 200 mails left to read and did not wanted to wait that long 
before writing down my comments. ;-)

regards
klaus

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

---

From: "Khan, Sohel Q [CTO]" <[email-masked]>
Date: Tue, 25 Jul 2006 14:21:07 -0500

Klaus,
Thank you for the input.
We updated the SPEERMINT Architecture draft significanlty and addressed
many of your concerns. 
We will make it publicly avaiable this Friday.

Sohel 
-----Original Message-----
From: Klaus Darilion [mailto:[email-masked]] 
Sent: Friday, July 21, 2006 6:55 AM
To: [email-masked]
Subject: [Speermint] comments on Peering Architecture Draft

Hi Sohel!

[...]

[...]

>    or TLS.  

or S/MIME or DTLS or whatever will come - no restrictions. --> "These
functions may be provided by using for example IPSec or TLS."

regards
klaus