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

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Mon, 3 Apr 2006 12:33:42 -0400

I agree.  Let's not get the tail wagging the dog here.

Product X needs to support the peering specification, not vice versa.

Mike

> -----Original Message-----
> From: Medhavi Bhatia [mailto:[email-masked]] 
> Sent: Monday, April 03, 2006 10:52 AM
> 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: "Hadriel Kaplan" <[email-masked]>
Date: Mon, 3 Apr 2006 17:19:23 -0400

Hi Michael,
That's a good point, and I'm not suggesting otherwise.  I think there may be
confusion about my email which I would like to clear up.  I have no doubt
product X (proxies, SBCs, whatever) would be changed to support a peering
specification, if their customers wished it.  It is, in fact, why I joined
this list!  :)

However, I am responding to Brian's question, which may be important (or
not) to WG members regarding the work of this WG.  I am NOT suggesting
devices (including SBCs) won't change specific things for this work.  Brian
asked: "should we care about them when thinking about this work?"  So my
response was: it depends.  There is a large installed base, which does
things for various reasons, so in my opinion we could hit issues if we do
not to take that into account.  We should support either model, so that the
applicability of Speermint is as broad as possible.  Since the charter
currently overlaps functions that SBCs do today, it would, in my opinion, be
less useful if the resulting work did not "care about them when doing this
work".  That's all.

-hadriel

> From: Michael Hammer (mhammer) [mailto:[email-masked]]
> Sent: Monday, April 03, 2006 12:34 PM
> To: Medhavi Bhatia; Livingood, Jason; Hadriel Kaplan
> Cc: [email-masked]