Subject: RE: [Speermint] [wg-business]WGLCfordraft-ietf-speermint-terminology-12

From: "Dan Warren" <[email-masked]>
Date: Wed, 3 Oct 2007 11:12:05 +0100

> -----Original Message-----
> From: Elwell, John [mailto:[email-masked]] 
> Sent: 03 October 2007 10:56
> To: Dan Warren; Uzelac, Adam; Daryl Malas
> Cc: Malas, Daryl; "Peterson, , dmm"@1-4-5.net; 
> [email-masked]; Livingood, Jason
> Subject: RE: [Speermint] 
> [wg-business]WGLCfordraft-ietf-speermint-terminology-12
> 
>  
> 
> > -----Original Message-----
> > From: Dan Warren [mailto:[email-masked]]
> > Sent: 03 October 2007 09:09
> > To: Elwell, John; Uzelac, Adam; Daryl Malas
> > Cc: Malas, Daryl; "Peterson, , dmm"@1-4-5.net; [email-masked]; 
> > Livingood, Jason
> > Subject: RE: [Speermint]
> > [wg-business]WGLCfordraft-ietf-speermint-terminology-12
> > 
> > > [JRE] Just getting back to terminology-12, in fact the 
> definition of 
> > > SSP makes no mention of UAC and UAS, but the definition of Peer 
> > > Network does. I think we have 3 issues here that have 
> been raised at 
> > > certain times in this thread:
> > > 
> > > 1. We should not try to distinguish between UAC and UAS. 
> If we need 
> > > to talk about UA, just use the term UA.
> > 
> > Agreed.
> > 
> > > 
> > > 2. What is the intended difference between a Peer Network
> > and an SSP?
> > > Are they totally different or is one a subset of the other? 
> > > Or are they the same (in which case we should have only a single 
> > > term)? Possibly a diagram showing relationships between Peer 
> > > Networks, SSPs and SPs would help. If it is hard to draw 
> a diagram 
> > > (e.g., things are not a simple hierarchy), then it 
> probably means we 
> > > have got something wrong.
> > 
> > Let me expand the problem you identify a little.  In the 
> terminology 
> > draft there are identified;-
> > 
> > -Service Providers, SIP Service Providers (which includes or is 
> > identical to ITSPs?), Peer Networks
> > 
> > -Layer 3 and Layer 5 interconnect, with subcategories of L5 
> i/c being
> > 	-Direct and Indirect Interconnect
> > 	-Assisted Interconnect (implicitly there must also be
> > Unassisted?)
> > 	-Dynamic and Static Interconnect
> > 
> > Because of the subcategories of L5 i/c, there is a lot of different 
> > permutations and combinations of different Provider types 
> that could 
> > be conceived, so it is going to prove very difficult to 
> come up with 
> > one picture.  In your architecture.  That is before you have 
> > considered third party access providers and mobile roaming.
> [JRE] But all I wanted is a diagram to show the relationship 
> between the
> 3 objects we are trying to define: Peer Network, SSP and SP. 
> I'm not necessarily saying that such a diagram needs to go 
> into the RFC, but it might help the discussion.

How about a description?

SP is operating at L3.
SSP is operating at L5 (and hence L3 so is a specialised SP).
Peer Network is an SSP with UA's.

Clearly not a final proposal (there aren't enough words and it doesn't
include any exceptions to the rules - a good definition always has
exceptions, right?), but maybe a starting point for you all to dissect
and destroy.

> 
> > 
> > > 
> > > 3. Is the inclusion of UAs a NECESSARY aspect of a Peer Network 
> > > and/or an SSP FOR THE PURPOSES OF SPEERMINT? Whilst in practice a 
> > > Peer Network or an SSP is likely to have UAs, is it of 
> relevance to 
> > > SPEERMINT discussions? Obviously for
> > > SSP(O) and SSP(T) there has to be an associated UA 
> (whether this is 
> > > part of the SSP or separate, I am not sure). But for
> > > SSP(t) the existence of UAs seems irrelevant to 
> SPEERMINT. So for a 
> > > general definition of SSP or Peer Network, from which we 
> can derive 
> > > definitions of more specialised objects (such as
> > > SSP(O)) if we wish, I would still argue that the 
> inclusion of UAs is 
> > > unnecessary.
> > 
> > I'd argue that SSP(t) is not a Peer Network.  SSP(O) and SSP(T) are 
> > Peering with each other, whilst SSP(t) is providing the 
> mechanism by 
> > which that Peering takes place.  Where it gets blurred is 
> if SSP(t) is 
> > doing more than just providing transit, but includes elements doing 
> > SIP profile interworking, transcoding (and transcoder insertion), 
> > reframing and so on.  That has a certain implication about the 
> > presence of a B2BUA, which I think is probably the (dare we use the 
> > phrase) peering point.  It's where the two protocol 
> profiles of SSP(O) 
> > and
> > SSP(T) clash,
> > but SSP(t) offers the interworking as part of a Federation 
> agreement, 
> > that the status of SSP(t) is called into question under current 
> > definitions...
> [JRE] I think you are saying that a Peer Network is a special 
> case of an SSP. SSP(O) and SSP(T) are Peer Networks, but 
> SSP(t) is not. So therefore can we define Peer Network in 
> terms of SSP?

See above... I think we ought to be able to.

> 
> > 
> > Dan
> > 
> > > 
> > > John
> > > 
> > > 
> > 
> > Forthcoming GSMA Events:
> >  
> > GSMA Mobile Asia Congress
> > Macau
> > 12 - 15 November 2007
> > www.mobileasiacongress.com
> >  
> > GSMA Mobile World Congress
> > Barcelona
> > 11 - 14 February 2008
> > www.mobileworldcongress.com
> > 
> > 
> > This email and its attachments are intended for the above 
> named only 
> > and may be confidential. If they have come to you in error you must 
> > take no action based on them, nor must you copy or show them to 
> > anyone; please reply to this email or call +44 207 759 2300 and 
> > highlight the error
> > 
> > 
> > 
> 
> 

Forthcoming GSMA Events:
 
GSMA Mobile Asia Congress
Macau
12 - 15 November 2007
www.mobileasiacongress.com
 
GSMA Mobile World Congress
Barcelona
11 - 14 February 2008
www.mobileworldcongress.com

This email and its attachments are intended for the above named only and may be confidential. If they have come to you in error you must take no action based on them, nor must you copy or show them to anyone; please reply to this email or call +44 207 759 2300 and highlight the error

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

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 03 Oct 2007 11:29:51 +0100

Dan,

> exceptions, right?), but maybe a starting point for you all to dissect
[JRE] OK, but in practice almost any SSP will be a Peer Network (even if
in certain use cases there is no UA involved, e.g., when acting as an
SSP(t)). So why do we need the term Peer Network? I notice it is not
used in the architecture draft, although it is used in the consolidated
use cases draft. Why can't we stick to SSP?

If we really need both terms, I don't believe the presence or absence of
UAs is an appropriate distinction.

John

---

From: Otmar Lendl <[email-masked]>
Date: Wed, 3 Oct 2007 14:05:59 +0200

On 2007/10/03 12:10, "Elwell, John" <[email-masked]> wrote:
> Dan:

<putting on my court-jester's cap>

That's simple.

Because this working group is named "session PEERING for ...", so the
authors assumed a need to talk only about "peering" (which is IMnsHO
the more-or-less direct interconnection between two networks for their
mutual benefit), even though some of the cases they describe is pure
"transit" which is only needed due to a lack of peering.

*shrug*

(Seriously: yes, we need to talk about transit. I just object to calling it peering.)

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

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 03 Oct 2007 14:19:42 +0100

Otmar,

I understand your point (and the point you made in your previous
posting). I think the concept of indirect peering was formulated before
I got actively involved in SPEERMINT, so I don't want to destabilise
that work. However, I do have some sympathy for what you say. Consider
the following case

UA --- Enterprise --- Carrier --- Carrier --- Enterprise --- UA
A          B             C           D             E          F

UA A on enterprise B makes a request to UA F on enterprise E. Enterprise
B sends all its requests to non-direct-peering domains via carrier C.
Enterprise E receives all its requests from non-direct-peering domains
via carrier E. According to the SPEERMINT concept of peering, Enterprise
B is peering with Enterprise E. Carrier C is not peering with Carrier D
or with Enterprise B. Carrier D is not peering with carrier C or with
Enterprise F. So in this case, Carrier C and Carrier D are not Peering
Networks. I am not sure this is a correct view. I understand that your
view would be that Enterprise B is peering with Carrier C, Carrier C is
peering with Carrier D, etc.. 

John

> From: Otmar Lendl [mailto:[email-masked]] 
> Sent: 03 October 2007 13:06
> To: [email-masked]
> Subject: Re: [Speermint]

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 8 Oct 2007 10:53:07 +0200

> Otmar,

John,

> that work. 

Feel free to join in the fun. As the terminology work seems to prejudice
some aspects of the final architecture, any input now is welcome.

> However, I do have some sympathy for what you say. Consider the following case
> 
> Networks. I am not sure this is a correct view. 

According to the currect definitions, this seems to be correct. 

> I understand that your

In the strict sense of the word, the peering would be just between C and D.
B-C and D-E might use the same protocol features for their interconnect,
but this is not a "meeting of peers", but likely a customer-supplier
interaction.

Just replace SIP by BGP: B-C and D-E becomes "IP upstream/downstream"
and only C-D is called "peering". 

The difference is more on the commercial side than on the technical side
(all three interfaces use BGP as the protocol). We do protocol design
here, thus we need no concern ourselves with that distincion.

/ol