RE: [Speermint] NATs and Firewalls

["Stastny Richard" <[e-mail]>]

> 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:[e-mail]]
> Sent: Thursday, April 06, 2006 2:50 AM
> To: Hadriel Kaplan; [e-mail]
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/speermint

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