Subject: Re: [Speermint] Updated: draft-ietf-speermint-terminology-13

From: Otmar Lendl <[email-masked]>
Date: Mon, 5 Nov 2007 17:12:40 +0100

On 2007/11/01 00:11, Daryl Malas <[email-masked]> wrote:
> 
> This revision updates the WGLC of rev 12 discussion points.  Please
> review the draft and provide feedback.

As promised, here is my review. IMHO we're getting there.

> 2.  SPEERMINT Context 
> 
>    Figure 1 depicts the general session peering context (Not in 
>    chronological order). Note that vertical axis in this figure 
>    describes the layering of identifiers, while the horizontal lines 
>    indicate working group scope. While the SPEERMINT working group is 
>    not limited (or coupled in any way) to the use of E.164 numbers, in 
>    the case shown here an E.164 number [5] is used as a key in an E.164 
>    to Uniform Resource Identifier (URI) mapping (ENUM [4]). The result 
>    of this step (which involves looking up Naming Authority Pointer 
>    (NAPTR) records in the DNS) is a SIP URI, on which the subsequent 
>    call routing is based. Note that the call routing step does not 
>    depend on the presence of an E.164 number. Indeed, the resulting SIP 
>    URI may no longer even contain any numbers of any type. In 
>    particular, the SIP URI can be advertised in various other ways, such 
>    as on a web page. 

Good.

>    Note that in Figure 1, Session Establishment Data (SED), is the data 
>    used to route a call to the called domain's ingress point (see 
>    Section 3.3 for additional detail). 

This is a bit ambiguous: is SED the input into the routing algorithm?
is SED the result of the routing algorithm? Some interim step?

>    As illustrated in Figure 1, the ENUM Working Group is primarily 
>    concerned with the acquisition of SED while the SPEERMINT Working 
>    Group is focused on the use of such SED in routing session signaling 
>    requests. Importantly, the SED can be derived from ENUM (i.e., an 
>    E.164 DNS entry) or via any other mechanism available to the user. 

As mentioned in the other mail: the user should never enter something
which is not a neutral Address-of-Records SIP URI. I hesitate to
call that SED. 

> 3.3. Session Establishment Data 
> 
>    Session Establishment Data, or SED, is the data used to route a call 
>    to the called domain's ingress point. A domain's ingress point can be 

Same as above: "route" is a bit ambiguous. What about:

|    Session Establishment Data, or SED, is the data needed to hand the
|    call to the next hop's ingress point. In the simplest case, this
|    information is derived from a SIP AoR using NAPTR/SRV/A record
|    lookups according to RFC 3263.

> 3.9. SIP Service Provider 
> 
>    A SIP Service Provider (or SSP) is an entity that provides 
>    application services utilizing SIP signaling to its customers. 

Stupid question: Do we actually care whether the SSP talks SIP with his
customers? We already dumped all the graphs depicting the internal setup
of a SSP as they are irrelevant to the peering question.

So, if any incumbent telco (DT, Qwest, TI, Telia, ...) decides to
use SIP for interconnection, is the fact that the customers themselves
are attached using POTS or ISDN lines an obstacle to the use of
speermint methods (whatever that may be)?

> 4.1. Layer 3 Peering 
> 
>    Layer 3 peering refers to interconnection of two service providers' 
>    networks for the purposes of exchanging IP packets which destined for 
>    one (or both) of the peer's networks. Layer 3 peering is generally 
>    agnostic to the IP payload, and is frequently achieved using a 
>    routing protocol such as Border Gateway Protocol (BGP) [6] to 
>    exchange the required routing information. 
> 
>    An alternate, perhaps more operational definition of layer 3 peering 
>    is that two peers exchange only customer routes, and hence any 
>    traffic between peers terminates on the peer's network or the peer's 
>    customer's network. 
> 
> 4.2. Layer 5 Peering 
> 
>    Layer 5 (Session) peering refers to interconnection of two service 
>    providers for the purposes of routing real-time (or quasi-real time) 
>    call signaling between their respective customers using SIP methods.  

This is a good description.

(This begs the question that given the similarities, why we need a
routing protocol on layer 3 and but not on layer 5. This draft does not
need to answer that, it is just terminology.)

> 4.2.2. Indirect Peering 
> 
>    Indirect, or transit, peering refers to the establishment of either a 
>    signaling and media path or signaling path alone via one (or more) 
>    referral or transit network(s). 

This is misleading. When I read this paragraph, I conclude that the
originating and terminating SSPs are peering (indirectly). Given your
last mails, this is not what you intend to say.

So what about:

|    A peering whose signalling (and optionally a media) path is also
|    used to carry calls originating or terminating not withing one
|    of the peering SSPs is called an indirect (transit) peering.
|    Any SSP in such a setup which is neither the originating nor
|    the terminating SSP is called a "transit network".

That's all a bit awkward.

Perhaps we need to introduce the concept of "reachability", i.e.
"is there a path via transit networks between SSP-O and SSP-T?"

(In order to keep the terminology in sync with Layer3 stuff, we
should not talk about primarily about "peering", but about
"interconnection". A "peering" is just a special case where the
set of announced routes is limited.)

> 4.3.1. Look-Up Function 
> 
>    The Look-Up Function (LUF) provides a mechanism for querying an 
>    internal and/or external database, which maintains a list of peered 
>    host domains. 

Could you be a bit more specific here? What exactly is the input
into the LUF, and what does the LUF return?

> 
> 4.3.2. Location Function 
> 
>    The Location Function (LF) develops SED by discovering the Signaling 
>    Function (SF), and SF's reachable host (IP Address and port). 

Again: what is the input? Output? Can you give examples?

That's it.

/ol
-- 
/ Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933 \
| nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H |
\ http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg /

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

---

From: "Livingood, Jason" <[email-masked]>
Date: Thu, 8 Nov 2007 13:30:34 -0500

Please upload this ID to the IETF site asap (today/tomorrow).  We should
always submit to the I-D editor at the same time that we post to some
private site for review for WG docs.

As soon as it is announced, we'll do a quick 2nd WGLC on -13.

Thanks
Jason 

> -----Original Message-----
> From: Daryl Malas [mailto:[email-masked]] 
> Sent: Wednesday, October 31, 2007 7:14 PM
> To: [email-masked]
> Subject: [Speermint] Updated: draft-ietf-speermint-terminology-13
> 
> In order to avoid several revisions prior to Vancouver, I 
> have place an updated draft here:
> http://www.malas.net-a.googlepages.com/draft-ietf-speermint-te
> rminology-13.txt
> 
> This revision updates the WGLC of rev 12 discussion points.  
> Please review the draft and provide feedback.
> 
> Thanks...
> 
> Daryl
> 
> 
> 
>

---

From: "Livingood, Jason" <[email-masked]>
Date: Thu, 8 Nov 2007 13:31:22 -0500

Keep in mind we're simply defining TERMINOLOGY here...

Jason 

> From: Otmar Lendl [mailto:[email-masked]] 
> Sent: Monday, November 05, 2007 11:13 AM
> To: Daryl Malas
> Cc: [email-masked]
> Subject: Re: [Speermint] Updated: draft-ietf-speermint-terminology-13
> 
> As mentioned in the other mail: the user should never enter 
> something which is not a neutral Address-of-Records SIP URI. 
> I hesitate to call that SED. 
> 
> >    to the called domain's ingress point. A domain's ingress 
> point can 
> > be
> 
> Stupid question: Do we actually care whether the SSP talks 
> SIP with his customers? We already dumped all the graphs 
> depicting the internal setup of a SSP as they are irrelevant 
> to the peering question.
> 
> So, if any incumbent telco (DT, Qwest, TI, Telia, ...) 
> decides to use SIP for interconnection, is the fact that the 
> customers themselves are attached using POTS or ISDN lines an 
> obstacle to the use of speermint methods (whatever that may be)?
> 
> > 4.1. Layer 3 Peering
> > 
> (This begs the question that given the similarities, why we 
> need a routing protocol on layer 3 and but not on layer 5. 
> This draft does not need to answer that, it is just terminology.)
> 
> > 4.2.2. Indirect Peering
> > 
> This is misleading. When I read this paragraph, I conclude 
> that the originating and terminating SSPs are peering 
> (indirectly). Given your last mails, this is not what you 
> intend to say.
> 
> So what about:
> 
> (In order to keep the terminology in sync with Layer3 stuff, 
> we should not talk about primarily about "peering", but about 
> "interconnection". A "peering" is just a special case where 
> the set of announced routes is limited.)
> 
> > 4.3.1. Look-Up Function
> > 
> Could you be a bit more specific here? What exactly is the 
> input into the LUF, and what does the LUF return?
> 
> > 
> > 4.3.2. Location Function
> >

---

From: Daryl Malas <[email-masked]>
Date: Thu, 08 Nov 2007 14:04:08 -0700

Done, look for it soon.