IETF speermint Working Group

Elwell, John | 3 Mar 2008 09:03

Comments on draft-ietf-speermint-requirements-04

Jean-Francois,

1. "SPP" - this is used several times, but not defined. The expressions
"session peering point" and "session peering policy" are used in various
places in the document - which does it mean? The phrase "parameters that
SPPs may consider" suggests neither of these expansions fits - it
suggests something like an administration.

2. "Session peering point" - this sounds like a new term, not defined in
the Terminology draft. I notice the Architecture draft uses "peeing
point", but that too is not defined in the Terminology draft. If we need
such a term, it should be common to the various documents, but given
that it seems to mean either signalling path border element or data path
border element, wouldn't "border element" be more appropriate?

3. "maximum flexibility should be given for how signaling path and media
   path border elements are declared, dynamically advertised and
   updated"
Why is updating of these elements relevant (software update,
presumably)? Should it instead refer to the updating of advertisements?

4. "media
   path border elements"
There is a defined term "data path border element" - use that.

5. "Note that this may not be
      applicable to all types of session peering (voice may be a
      particular case where this is needed -- at least based on current
      practices)."
This note refers to the advertisement of egress SBEs, so why does the

(Continue reading)

headers

Elwell, John | 3 Mar 2008 09:03

Comments on draft-ietf-speermint-architecture-05

1. "Two SSPs can form a Layer 
   5 peering over either the public Internet or private Layer3 
   networks. In addition, two or more providers may form a SIP (Layer 
   5) federation [13] on either the public Internet or private Layer 3 
   networks."
This does not cover the case where one SSP is on the public Internet and
the other is on a private L3 network, or federations that span the
public Internet and one or more private L3 networks. Similarly the
bullets further down do not consider this possibility.
Consequently, the distinction between "Public Peering Function" and
"Private SIP Peering" in figure 1 becomes blurred. Since those terms are
not used in the rest of the document, they should be removed.

2. "Peering point" (2 instances). This is not a defined term.

3. "This document assumes that a call from a UAC end user in the 
   initiating peer's network goes through the following steps to 
   establish a call to a UAS in the receiving peer's network:
....
....
....4. the discovery of the UAS"
I am not quite sure how to interpret this list of steps, but step 4
isn't a step taken by the initiating peer's network - it is taken by the
terminating SSP. Perhaps the list of steps was intended to cover steps
taken by either domain. But then in this case, is order supposed to be
significant? Step 5 "Routing of SIP messages" has to occur (at least
routing as far as the terminating SSP) before discovery of the UAS.

5. "5.1. The Location Function (LF) of an Initiating Provider"
LF is not a defined term in the Terminology draft, and also it doesn't

(Continue reading)

headers

Hadriel Kaplan | 4 Mar 2008 21:07

Comments on draft-ietf-speermint-architecture-05

Howdy,
here are my comments on sections 1-3, fwiw:

--------------------------
Section 3:
I like the idea of having an overview of the steps required, but this section is confusing. The first
paragraph says:
This document assumes that a call from a UAC end user in the
initiating peer's network goes through the following steps to
establish a call to a UAS in the receiving peer's network...
that implies the steps are for the UAC to perform? (presumably not) Or does it mean for the "call" to perform?
(which is weird in concept and wording here)

Step 2 says "the discovery of the receiving peering point address" - it should mean the destination peering
point address, right? In Figure 2 the words "Target SSP" are used, which is probably what should be used here.

Step 3 could happen even if the target represents an intra-SPP resource.

Step 4 "the discovery of the UAS" is a bit odd, because for intra-SSP requests it may or may not require
additional steps (e.g., finding the right Registrar and sending it to that), and for inter-SSP requests
only the target SSP does this, not the originating SSP. It's also odd because step-5 happens before step-4
in many cases.

Step-5 "the routing of SIP messages" is not a single step that can be enumerated in this one step - it is
incorporated in or among several of the steps.

Therefore, I propose the following replacement to section 3:

"This document assumes that a call from a UAC in the originating peer's network to a UAS in the target peer's
network requires the following steps to be taken, as requests get routed from one SSP to another:

(Continue reading)

headers

Hadriel Kaplan | 5 Mar 2008 03:50

Comments on section-4 of draft-ietf-speermint-architecture-05

Following are comments for section 4:

Figure 2: what do the arrows represent?  That data is installed/provisioned from the LUF to the LRF?
And what does the line from the LRF to the SBE represent?

I think internally, inside an SSP, it doesn't matter how the SSP goes about performing the LRF/LUF lookup -
it may well matter to Peppermint, but not Speermint.  By that I mean the LRF and LUF "lookup" may be done by the
UAC, a proxy in the middle, or an SBE.  And the "lookup" could be a query or provisioned data.  And how the
LRF/LUF are populated, instantiated, and queried are up to Peppermint, presumably.

All that matters to Speermint is that for a given target URI, the originating SSP determines (a) the
terminating SSP via LUF, (b) how to get to the terminating SSP through proxies/SBE's/whatever via LRF,
and (c) how the SSP modifies the request-URI or inserts Route headers to get it there.

For the terminating SSP, all that matters is how it should expect to receive a target URI (i.e., in req-uri or
Route headers), and how it gets it to the UAS is basically it's own business.  In that sense, showing a
LUF/LRF in the terminating SSP is not relevant.

-hadriel

headers

Hadriel Kaplan | 5 Mar 2008 04:59

Re: Comments on section-5.1 and 5.2 of draft-ietf-speermint-architecture-05

Comments on sections 5.1 and 5.2...

The title of section 5 "Peer Function Examples" is a misnomer, I think. It is neither about the "Peer" nor
really examples. It is really "Recommended SSP Procedures" or some such.
Likewise, section 5.1's title should be "Originating SSP Procedures", and section 5.2's should be
"Terminating SSP Procedures".

Section 5.1 LF function: This section seems to collapse the LUF and LRF functions into one, which is a shame
because I really liked that distinction/separation. If you want text for this to reflect the Figure 2
separation, where the two are separate functions, I can provide it.

Section 5.1.1 target URI: paragraph 3 says:
...If the highest
priority supported URI scheme is sip: or sips:, the initiating peer
skips to SIP DNS resolution in Section 5.1.5. Likewise, if the
target address is already a sip: or sips: URI in an external domain,
the initiating peer skips to SIP DNS resolution in Section 5.1.5.
I'm not quite sure why it says this. It is basically a matter of local policy to the originating SSP, whether
it wants to use DNS at all to direct-route such requests, or whether it wants to perform a LUF/LRF lookup,
Infrastructure ENUM lookup, etc.

Section 5.1.2 User ENUM: Is this section in here to be politically correct? 'cause this is super-rare
today, obviously.

Section 5.1.3 DNS resolution:
It says in paragraph 2:
When communicating with a public external peer, entities compliant
to this document MUST only select a TLS-protected transport for
communication from the initiating peer to the receiving peer.
I believe this document is Informational, so having a MUST statement is not allowed. Furthermore, it would

(Continue reading)

headers

Otmar Lendl | 6 Mar 2008 11:15

Re: I-D Action:draft-lendl-speermint-background-01.txt

On 2008/02/26 18:02, Daryl Malas <D.Malas@...> wrote:
> Otmar,
> 
> I also enjoyed reading the draft.  I think you bring up some very
> interesting and valid discussion points.  I also think you re-enforce
> there is much to do within SPEERMINT.

Thanks for the kind words to everybody.

> A comment to the use case authors...please read this draft, because I
> think it has some important topics to touch on in your draft.

The most important one (IMHO, of course) is, that the current speermint
charter does not allow us to tackle the real issue. We're re-arranging
the existing RFCs on the sinking email-model for SIP. 

This approach will result in hopefully improved private peering setups,
but fail to establish a new routing architecture for SIP calls, thus
further undermining the end2end principle even for those willing to do
*some* peering over the public Internet.

> Thank you, Otmar, for taking the time to update this draft. 

The thanks go to Hannes for his input and the encouragement to repost
the draft as input to the rucus EG.

/ol
--

-- 
// Otmar Lendl <lendl@...>, T: +43 1 5056416 - 33, F: - 933
// nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H

(Continue reading)

headers

Paul Erkkila | 7 Mar 2008 16:58

Re: Comments on draft-ietf-speermint-architecture-05

Elwell, John wrote:
> 1. "Two SSPs can form a Layer 
>    5 peering over either the public Internet or private Layer3 
>    networks. In addition, two or more providers may form a SIP (Layer 
>    5) federation [13] on either the public Internet or private Layer 3 
>    networks."
> This does not cover the case where one SSP is on the public Internet and
> the other is on a private L3 network, or federations that span the
> public Internet and one or more private L3 networks. Similarly the
> bullets further down do not consider this possibility.
> Consequently, the distinction between "Public Peering Function" and
> "Private SIP Peering" in figure 1 becomes blurred. Since those terms are
> not used in the rest of the document, they should be removed.
> 

For the 2 SSP case a direct peer is already covered since you can just 
pick which address space you want co consider as the primary right?

Direct:
[SSP-A] <-net1|<voodoo>|net2-> [SSP-B]

So are you thinking of the indirect case?

Indirect:
[SSP-A] <-net1-≥ [(SSP-N + voodoo)+] <-net2-≥ [SSP-B]

For federations it looks like we need some wording that deals with 
multiple address space issues within federations. I'm not sure which 
doc(s) that would go into though.

(Continue reading)

headers

Elwell, John | 10 Mar 2008 12:52

Re: Comments on draft-ietf-speermint-architecture-05

Paul,

I was thinking of the direct case too, e.g., one user in enterprise
space, one in public space.

John 

> -----Original Message-----
> From: Paul Erkkila [mailto:pee@...] 
> Sent: 07 March 2008 15:59
> To: Elwell, John
> Cc: speermint@...
> Subject: Re: [Speermint] Comments on 
> draft-ietf-speermint-architecture-05
> 
> Elwell, John wrote:
> > 1. "Two SSPs can form a Layer 
> >    5 peering over either the public Internet or private Layer3 
> >    networks. In addition, two or more providers may form a 
> SIP (Layer 
> >    5) federation [13] on either the public Internet or 
> private Layer 3 
> >    networks."
> > This does not cover the case where one SSP is on the public 
> Internet and
> > the other is on a private L3 network, or federations that span the
> > public Internet and one or more private L3 networks. Similarly the
> > bullets further down do not consider this possibility.
> > Consequently, the distinction between "Public Peering Function" and
> > "Private SIP Peering" in figure 1 becomes blurred. Since

(Continue reading)

headers

Daryl Malas | 10 Mar 2008 15:23

Comments on Requirements Draft rev.04

Jean-Francois,

I have some comments regarding the requirements:

Requirement #2:
      "Protocol mechanisms should exist for a SIP Service Provider (SSP)
      to communicate the egress SBEs of its service domain."

[DM] IMO, this looks more like a provisioning parameter for the SSP.
Why would a SSP communicate this information?  Wouldn't this information
be pertinent to the SSP itself?  For example, I do not care what SBEs my
peer chooses to use to egress traffic.  Now, that being said, I might
want to know what IP addresses the peer "might" originate their traffic
to me from, but in the "SIP world" this is not a reality.  The only
purpose of this, I can think of, is for me to implement ACL's for
allowing traffic only from a specific set of peer addresses.  At best,
this implementation choice would be a MAY and not a requirement.

Requirement #3: (see comment on Req #2)

"Some SSPs may have some restrictions on the type of media traffic
   their SIP entities acting as SBEs are capable of establishing.  In
   order to avoid a failed attempt to establish a session, a mechanism
   may be provided to allow SSPs to indicate if some restrictions exist
   on the type of media traffic: ingress and egress SBE points may be
   peer-dependent, and/or media-dependent."

[DM] This seems more like a "policy" requirement on codecs or service
types, yet there is no mention of policy in the requirement.

(Continue reading)

headers

Reinaldo Penno | 10 Mar 2008 21:15

Re: Comments on draft-ietf-speermint-architecture-05

Hello John,

Thanks for your very detailed review. I went though your comments. Please
see my comments inline...

On 3/3/08 12:03 AM, "Elwell, John" <john.elwell@...> wrote:

> 1. "Two SSPs can form a Layer
>    5 peering over either the public Internet or private Layer3
>    networks. In addition, two or more providers may form a SIP (Layer
>    5) federation [13] on either the public Internet or private Layer 3
>    networks."
> This does not cover the case where one SSP is on the public Internet and
> the other is on a private L3 network, or federations that span the
> public Internet and one or more private L3 networks. Similarly the
> bullets further down do not consider this possibility.
> Consequently, the distinction between "Public Peering Function" and
> "Private SIP Peering" in figure 1 becomes blurred. Since those terms are
> not used in the rest of the document, they should be removed.

Irrespective of where two SSPs are located they can either peer over a
private network and/or a public network. Is there are other way?

Instead of adding another bullet I could make the statement generic to cover
all possible permutations.

As far as federation goes, they can peer over both (private and public). But
it still just two possibilities. I can consolidate the drawing to say
"private/public" in the same cloud and just connect everything to it. In the
process I can remove the boxes "Private peering function" and Public peering

(Continue reading)

Mon	Tue	Wed	Thu	Fri	Sat	Sun

					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30
31

4	November 2011
3	October 2011
1	September 2011
2	August 2011
3	June 2011
4	March 2011
7	February 2011
4	January 2011
5	December 2010
12	November 2010
3	October 2010
4	September 2010
2	August 2010
9	July 2010
19	June 2010
24	May 2010
2	April 2010
39	March 2010
9	February 2010
15	January 2010
18	December 2009
9	November 2009
14	October 2009
15	September 2009
3	August 2009
9	July 2009
8	June 2009
1	May 2009
1	April 2009
26	March 2009
21	February 2009
2	January 2009
2	December 2008
49	November 2008
6	October 2008
1	September 2008
5	August 2008
10	July 2008
13	June 2008
21	May 2008
7	April 2008
25	March 2008
57	February 2008
44	January 2008
49	December 2007
46	November 2007
43	October 2007
8	September 2007
19	August 2007
36	July 2007
19	June 2007
18	May 2007
99	April 2007
21	March 2007
71	February 2007
16	January 2007
10	December 2006
44	November 2006
225	October 2006
201	September 2006
216	August 2006
208	July 2006
207	June 2006
159	May 2006