Subject: RE: [Speermint] Speermint Charter (now re SBCs)

From: "Stastny Richard" <[email-masked]>
Date: Mon, 3 Apr 2006 17:21:30 +0200

I tend to agree with Medhavi that from the point of the Core-O
it does not matter very much if a given an AoR is to be routed<
to a SIP proxy direct via a SBC pretending to be one or an I-CSCF
or whatever.

This is also ok with the ENUM Charter talking about discovering
points of interconnect

This may be an issue later regarding transparent end2end
user connections, but one problem after the other

Richard

> -----Original Message-----
> From: Medhavi Bhatia [mailto:[email-masked]]
> Sent: Monday, April 03, 2006 4:52 PM
> To: Livingood, Jason; Hadriel Kaplan
> Cc: [email-masked]
> Subject: RE: [Speermint] Speermint Charter (now re SBCs)
> 
> Hi Jason,
> 
> Our focus at this point should be trying to keep it simple and
> practical. Commercial choices (whether to use SBCs, firwewalls or SIP
> proxies) for peering should be kept out of scope of the charter. The
> specification of any sort of architecture can be very consuming at
this
> point and the usefulness is quite limited.
> 
> I suggest starting with the following simple use cases which have no
> architecture implications or dependencies:
> 
> - Direct peering between Core-O and Core-T
> 	o Technology required (ENUM/DNS, SIP Requirements)
> - Peering with IXP in the middle
> 	o Technology required (ENUM/DNS, SIP Requirements)
> 
> In addition, the role of federations and IXPs needs to be well
> documented since that affects the technology we develop or use.
> 
> -Medhavi.
> 
> > -----Original Message-----
> > From: Livingood, Jason [mailto:[email-masked]]
> > Sent: Monday, April 03, 2006 8:41 AM
> > To: Hadriel Kaplan
> > Cc: [email-masked]
> > Subject: RE: [Speermint] Speermint Charter (now re SBCs)
> >
> >
> > > To your question of "does it matter if they go through SBCs
> > > for our work?"
> > > So, to your actual question: it depends.  If the end goal of
> > > this WG is to define BCPs of call flows for peering, then
> > > that's easy: someone can just send an ethereal trace. :)  If
> > > it's to define best future (vs.
> > > current/common) practices, then yes it may hit issues if the
> > > reality (from my perspective) isn't taken into account.  It's
> > > like talking about IP peering without acknowledging routers
> > > exist.  The irony from my perspective is what SBCs do
> > > "differently" is used by many for very valuable
> > > peering-related benefits.
> >
> > I suspect this issue will continue to arise every so often as it has
> > before (which is okay, by the way; continued discussion is generally
a
> > signal of a lack of consensus).  IMHO, the architecture and BCPs
> > proposed will need to show how you can do SIP peering without and
with
> > session border elements.  There are some domains that will not want
to
> > use them, and some that will want to use them.  And even where a
> domain
> > prefers to use such an element, it may be application-specific such
> that
> > it is perhaps used for SIP-VoIP but not for SIP-IM.
> >
> > Anyway, I think the point is that I don't expect we'll try to
dictate
> > that session border elements absolutely must or must not be used.
For
> > some domains with particular requirements (business, IP networking,
IP
> > addressing, whatever), for some applications, such elements may make
> > sense and may be considered.  For those that feel strongly about the
> > fact that use of such elements are not a good trend, we should be
able
> > to spell out how a domain can meet all of their requirements and
> deploy
> > a SIP peering architecture without them if they so choose (and so
> we'll
> > ask for your constructive assistance on such work).  Thus, we first
> > describe requirements, then we describe all of the different
> > architecture options that would accomodate those requirements, and
> then
> > implementers better understand all of the issues and can make
> decisions
> > based on this expert information as well as their own particular
> needs.
> >
> > Jason
> >
> > _______________________________________________
> > Speermint mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/speermint
> >
> > --
> > No virus found in this incoming message.
> > Checked by AVG Free Edition.
> > Version: 7.1.385 / Virus Database: 268.3.4/299 - Release Date:
> 3/31/2006
> >
> 
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint

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

---

From: David Meyer <[email-masked]>
Date: Mon, 3 Apr 2006 15:08:08 -0700

On Mon, Apr 03, 2006 at 10:54:54PM +0100, Eli Katz wrote:
> >	Do you think we need to add terminology (to the
> >	terminology draft) for these last 2?
> >
> >	Dave
> 
> Dave,
> 
> I certainly feel it would be helpful to provide some
> terminology/definition of Federations / IXPs, and if reqd, can help.

	Ok, thnx. I have a huge number of changes to put into
	that do, so let me get a -00.txt out (it will be -00
	since it will have a new name), then we can work on
	that. 
> There is a wide variety today of IP Communications Federations, all of
> which are involved in voip peering, both in the real-world, and as
> referenced in various I-Ds posted to this group (e.g. Otmar, Medhavi
> etc..). They exist in their various forms, as the multi-lateral (aka
> federation) type approach to interconnection/peering, is usually far
> more scalable then the n*n bi-lateral approach to interconnection, which
> is the basis for much of the (legacy!) telecoms interconnects today.

	Understood.

> Bringing (some) clarity to the different types and roles of the
> federations, is likely to enable a more focussed discussion and useful
> output.

	Yes, that would seem useful.

> Looking thru the current I-Ds, the types of Federations (Groups of
> ITSPs) range from some OR all of the following :-
> 
> 	- a virtual Federation of ITSPs with common policy (both the
> ad-hoc concept and the pre-agreed)
> 	- with Federated (Private) ENUM / DNS / SRV trees, including
> Origination based responses (a more secure/flexible version of
> split-dns)
> 	- with Layer 5 signalling (e.g Interconnect SP)
> 	- Hubbing of Media (e.g IPX) (optional QoS) - usually standard
> L2 / L3 IP peering
> 	- Security, Trust, Best Practice and Identity management and
> policy 
> 
> BTW all the above can (and does!) exist in public or private IP space..

	Yep...

> To reinforce, previous messages on this point, all of the above, and
> federations in general, are not and should not be mandatory, as the only
> speermint architecture solution. Rather it is simply one of the viable
> voip peering methodologies (as used by numerous communications service
> providers of all types throughout the world today), and we should keep
> our charter as reasonably broad as possible, and certainly, wherever
> possible, not to exclude real-world activities.

	Agreed.

	Dave

> 
> Eli
>  
> PS this could also help clarify the 3.6.2 L5 issue ..
> PPS Hopefully the Layer 8 (Commercial), Layer 9 (Political) and Layer 10
> (Philosophical) issues can be and will be ignored.. :-)
> 
> From: David Meyer [mailto:[email-masked]] 
> Sent: 03 April 2006 19:50
> To: Medhavi Bhatia
> Cc: [email-masked]; Livingood, Jason
> Subject: Re: [Speermint] Speermint Charter (now re SBCs)
> 
> 	Medhavi,
> 
> > practical.
> 	Exactly.
> > Commercial choices (whether to use SBCs, firwewalls or SIP
> > this point and the usefulness is quite limited.
> 
> 	I agree, at least initially.
> 
> 	Do you think we need to add terminology (to the
> 	terminology draft) for these last 2?
> 
> 	Dave
> 
> 
> > 
> > -Medhavi.
> > 
> > > > To your question of "does it matter if they go through SBCs for 
> > > > our work?"
> > > > So, to your actual question: it depends.  If the end goal of this 
> > > > WG is to define BCPs of call flows for peering, then that's easy: 
> > > > someone can just send an ethereal trace. :)  If it's to define 
> > > > best future (vs.
> > > > reality (from my perspective) isn't taken into account.  It's like
> 
> > > > talking about IP peering without acknowledging routers exist.  The
> 
> > > > irony from my perspective is what SBCs do "differently" is used by
> 
> > > > many for very valuable peering-related benefits.
> > > 
> > > a signal of a lack of consensus).  IMHO, the architecture and BCPs 
> > > with session border elements.  There are some domains that will not 
> > > want to use them, and some that will want to use them.  And even 
> > > where a
> > domain
> > > dictate that session border elements absolutely must or must not be 
> > > used.  For some domains with particular requirements (business, IP 
> > > networking, IP addressing, whatever), for some applications, such 
> > > elements may make sense and may be considered.  For those that feel 
> > > strongly about the fact that use of such elements are not a good 
> > > trend, we should be able to spell out how a domain can meet all of 
> > > their requirements and
> > deploy