Subject: RE: [Speermint] NATs and Firewalls

From: "Stastny Richard" <[email-masked]>
Date: Thu, 6 Apr 2006 09:11:57 +0200

> I think the problem we are trying to solve in the WG is definition of
a
> specific SIP signaling profile (as defined by this WG at some point I
> guess) and location mechanism for next hop (again TBD from this WG)
> which will enable successful hand-off of the call between domains.
This
> is clearly my interpretation and the chairs may think o/w. We should
not
> be taking the SBC functions as defined somewhere (especially since
they
> are incomplete) and try to write BCPs on them. We should be defining
> interfaces in this WG, not elements, architecture etc.

Yep, at least this should be our first priority

> L3 is out of scope... I think that I am pretty sure of. I am not sure
> what you mean by peering L3 VPNs in speermint's context.

Also, yes, again L5 is first priority

Richard

> -----Original Message-----
> From: Medhavi Bhatia [mailto:[email-masked]]
> Sent: Thursday, April 06, 2006 2:50 AM
> To: Hadriel Kaplan; [email-masked]
> Subject: RE: [Speermint] NATs and Firewalls
> 
> >
> Hi Hadriel,
> 
> See below.
> 
> 
> > I think what may be the issue is our definition of SBCs may simply
not
> be
> > the same.  Maybe you feel all the functions of modern SBCs are all
> > implemented in a single physical box, which is not the case from my
> view at
> > all.  The functions can be broken up, or not.  It does not matter
from
> the
> > context of this working group, because the peering partner is a
single
> > logical entity and it's the requirements that must be covered, not
the
> > implementations meeting those requirements. (as pointed out to me
> earlier!
> > :)
> 
> I think that is the problem today. There are too many SBC definitions
> and behaviors. This is the result of different point solutions for
> similar requirements given by service providers in different
> circumstances (fixed, mobile etc). Clearly something this
under-defined
> cannot be taken into account by the WG when making choices. That's
what
> I essentially said in an earlier thread on WG scope. We need to get
all
> the requirements on the table and be practical about them. SBCs are
out
> of scope...
> 
> 
> > My only point relative to what should be "required", is
applicability
> to
> > as broad a spectrum of providers as possible, where covering the
case
> of L3
> > VPNs is probably the broadest approach, and within the IETF's
domain.
> >
> > Or maybe you feel the definition of "SBC" _requires_ media relaying
> > somewhere?  That is not the case for any of the current physical
> > implementations of SBCs that I know of in the service-provider
market.
> It
> > happens to be that many providers enable them to do that, for many
> reasons
> > way beyond "point" requirements.  For example, I consider
> media-relaying for
> > the purpose of hosted-nat-traversal a "point" requirement.  Someday
it
> will
> > fix itself.  But that's not why many providers relay media, and
> certainly
> > not in peering applications; and some providers don't relay media
with
> their
> > SBCs.
> >
> 
> I think in the speermint we should look at the problem of peering
during
> session setup. After the setup phase, the service providers may decide
> to do media peering or not. We should tackle those requirements later
> on.
> 
> > Regardless, in my view even if the SBC does not relay media it's
still
> an
> > SBC if it performs other functions related to security,
inter-working,
> > policies, etc.  Some of those functions are described in
> > draft-camarillo-sipping-sbc-funcs-03.txt, which I believe you helped
> author.
> > Clearly at some point as you remove those functions it ends up being
> just a
> > proxy.
> 
> B2BUA to be precise. If I remove those functions, I will still be left
> with a lot more functions! (it is not easy to document all SBC
> functions, especially since there is no clear definition or
requirements
> out there on functions or expected behavior. We only mention some in
> that draft).
> 
> But since a large group of providers appear to want some or all of
> > those functions (and more) today, at peering points, then a peering
> BCP for
> > peering providers would be most successful if it "worked" within the
> > constraints of those wants while providing BCPs to enable new
services
> or
> > applications.
> >
> 
> I think the problem we are trying to solve in the WG is definition of
a
> specific SIP signaling profile (as defined by this WG at some point I
> guess) and location mechanism for next hop (again TBD from this WG)
> which will enable successful hand-off of the call between domains.
This
> is clearly my interpretation and the chairs may think o/w. We should
not
> be taking the SBC functions as defined somewhere (especially since
they
> are incomplete) and try to write BCPs on them. We should be defining
> interfaces in this WG, not elements, architecture etc.
> 
> > I think the simplest way to do it is to simply also cover the case
of
> L3
> > VPNs peering with each other.  Do you disagree with that?  Any
> "services" or
> > applications which cannot be met by peering L3 VPNs, may be
documented
> as
> > such in the BCPs, as far as I care.
> >
> 
> L3 is out of scope... I think that I am pretty sure of. I am not sure
> what you mean by peering L3 VPNs in speermint's context.
> 
> -Medhavi.
> 
> _______________________________________________
> 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: Thu, 6 Apr 2006 15:55:25 -0400

Hi Richard and Medhavi,
Comments inline. 

> From: Stastny Richard [mailto:[email-masked]] 
> Sent: Thursday, April 06, 2006 3:12 AM
> To: Medhavi Bhatia; Hadriel Kaplan; [email-masked]
> We should

And no one said we should. (at least I never intended to)  I have said,
again and again, I am not proposing we mandate nor even mention SBCs in any
documents.  The entire conversation started because someone asked "does it
matter if it crosses them" and I said it may.  If some of the market uses
them to do things for peering reasons, then perhaps we should address the
needs of that part of the market as well, by not excluding them.  Not by
definining SBCs, not by requiring SBCs.  

At this point I regret having mentioned the term "SBC" because it's provided
a lightning rod of hysteria and confusion when the point of my response was
simply to suggest the requirements should be as open and broad as possible
to achieve the goals of the WG.  As I said, I think the best way to describe
them, is if you imagine a peer's voip network is in it's own L3 VPN, which
is an IETF-acceptable concept based on the work of other WGs.

What that means, essentially, is of course there are one or more entry/exit
peering points from/to that peer. (ie, proxies)  And of course the peering
proxy(s) points must share the same address space as the partner peer's
exit/entry proxies.  Both at a L3 IP level and at a L5 SIP level.  What it
does NOT mean, however, is that any nodes inside the L3-VPN peer's network
are directly addressable at an L3 IP-Address level (FQDN is another matter).
And naturally if we care about media (as the charter and I think most people
using SIP today do), then we'll need to take into consideration the L3-VPN
issues.  How, or even IF, we fix them or address them or not I am NOT
proposing, and I don't think we'll need to in the end.  It's merely the
recognition of such networks as legitimate peering partners that I request
be considered.

As several people have said, this whole concept may not make one bit of
difference in the end.  Or it may.  I don't know until the requirements are
done and the BCP ideas/mechanisms are discussed.  
Yeesh.  :)

-hadriel