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

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Mon, 3 Apr 2006 19:10:09 -0400

Hadriel,

Some folks think that SBC's are supposed to be transparent, but what I
think you are pointing out is that SBCs may already do some degree of
peering and thus any new peering requirements represent a backwards
compatibility problem for you, but perhaps also an opportunity for the
IETF to mine lessons learned.

Mike

> -----Original Message-----
> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: Monday, April 03, 2006 5:19 PM
> To: Michael Hammer (mhammer)
> Cc: [email-masked]
> Subject: RE: [Speermint] Speermint Charter (now re SBCs)
> 
> 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
> 
> 
> > -----Original Message-----
> > 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]
> > Subject: RE: [Speermint] Speermint Charter (now re SBCs)
> > 
> > I agree.  Let's not get the tail wagging the dog here.
> > 
> > Product X needs to support the peering specification, not 
> vice versa.
> > 
> > Mike
> > 
> > 
> 

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

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Tue, 4 Apr 2006 02:15:43 -0400

Hi Mike,
Yes, I have heard that question from several people recently, much to my
surprise.  The term "SBC" is defined by the vendors, and it doesn't always
mean the same thing these days, but I don't know of any SBC vendors in the
service provider space who are "transparent".  (And I know most of them)
They are not firewalls.  They are an addressed entity from all "sides", and
they typically appear as a B2BUA, depending on who makes it and how they're
deployed.

But no, any new requirements don't represent a backwards-compatibility
problem for me.  If the WG adds new requirements my guess is any SBC vendor
would implement them, if their customers wanted them to and it was
technically sound.  If you want to peer across to the current ones, then
obviously it could be an issue.  I'm not saying everyone uses them, but it's
pervasive enough that if you cross more than one provider the odds are very
high. (which is why I said the multi-provider issue is more interesting
personally, in another email)

There are some things SBCs do which have intrinsic value to those operators,
and thus there are some facets which cannot be changed and would be
fruitless to mandate against, IMHO.  They are not, as some people think,
used to block reachability of users to the Internet.  They are in many ways
the inverse.

So I agree with Jason that the best model would be one which encompassed all
of the ways.  And that was my point as well.  :)

-hadriel

> Sent: Monday, April 03, 2006 7:10 PM
> To: Hadriel Kaplan
> Cc: [email-masked]