RE: [Speermint] NATs and Firewalls

["Medhavi Bhatia" <[e-mail]>]

> 
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