Subject: RE: [Speermint] Reachability

From: "Reinaldo Penno" <[email-masked]>
Date: Thu, 6 Apr 2006 04:04:42 -0400

Let me take this further.

If A performs only _VoIP peering_ with B, there is nothing precluding it
from peering with C directly too, unless we have a totally segregated
network.

So, physically it would look something like this

-------         --------       -------
|  A  |=========|  B   |       |  C  |
|     |========================|     |
-------         --------       -------

But logically it would be like this

A  ===== B
 \
  \ 
   \
    C

Sorry for the text graphics.

> -----Original Message-----
> From: Reinaldo Penno
> Sent: Thursday, April 06, 2006 12:55 AM
> To: Stastny Richard; Lee, Yiu; Hadriel Kaplan; [email-masked]
> Subject: RE: [Speermint] Reachability
> 
> I'm having a hard time understanding the complications...Sorry but I'm
> going to ask basic questions again before we dwell in many (more)
> discussions. It _seems_ to me we are overly complicating each topic.
> 
> Are A and C paying B to carry _IP_ packets (which includes signaling
and
> media)? Can A send and receive packets from C? So, unless A and C want
> something special done to their signaling traffic I wonder what B has
to
> do with it... Why would I pay B to be a proxy hop if I can send
packets
> directly? Are A and C concerned with security, or wondering how to
peer
> directly? Well, then peer directly over a TLS connection.
> 
> Also, I do not understand "transit services" in this context. This is
> not the PSTN. We are talking IP backbones, right?
> 
> I'm assuming A has DNS access and so has C. They can figure out by
> themselves the "sip route" of the signaling services. There is nothing
> SIP related that B can provide that A and C cannot figure out. The
> endpoints are in A and C; B does not have control over the E.164
> numbers, ENUM, SIP URIS, etc.
> 
> I can have a SIP TLS connection from my house over 5 different
backbones
> and peer with another proxy server in Japan. That's the fundamental of
> Layer 5 peering, no? It is an overlay network over IP. Unless some
> carrier/provider has some access list, I wonder what the problem is.
> 
> Now, maybe I'm missing something, maybe we need to hash out this
example
> further.
> 
> Regards,
> 
> Reinaldo
> 
> > -----Original Message-----
> > From: Stastny Richard [mailto:[email-masked]]
> > Sent: Thursday, April 06, 2006 12:05 AM
> > To: Lee, Yiu; Hadriel Kaplan; [email-masked]
> > Subject: RE: [Speermint] Reachability
> >
> > Inline
> >
> > > -----Original Message-----
> > > From: Lee, Yiu [mailto:[email-masked]]
> > > Sent: Thursday, April 06, 2006 1:22 AM
> > > To: Hadriel Kaplan; Stastny Richard; [email-masked]
> > > Subject: RE: [Speermint] Reachability
> > >
> > > This is an interesting thread especially for the scenario A-B-C
> where
> > B
> > > is providing transit services. In near term , I don't see any
> operator
> > > will like to provide transit services since I don't smell money in
> > this
> > > area ;-) Also, if A doesn't peer C directly, we have our old
friend
> > PSTN
> > > to do the work (at least working for the voice service).
> >
> > No, you do NOT have the Good old PSTN to do the work in SPEERMIND
> > SPEERMINT (peering, interreconnect; whatever) is not E.164 aware,
> > so the PSTN is NOT an Option
> >
> > > The
> > > complication of providing transit services is to guarantee service
> > > delivery. In theory, the SIP proxy in B doesn't need to
record-route
> > > itself so that it can leave the signaling path as soon as A & C
> > > establish the session. Reality is B must stay in the signaling
path
> > > because A signed a peering agreement with B and B signed a peering
> > > agreement with C, there is no agreement between A & C and the
> > agreement
> > > is not transitive. If A sends a mid-dialog request directly to C,
> C's
> > > policy may probably reject it. For the media flow, I also argue
that
> > > even if A & C have directly IP peering connectivity, A's media
> traffic
> > > should flow through B's IP network then to C's IP network.
> >
> > You are implying L3 peering is atomatically with L5 peering,
> > I thought we had this one
> >
> > > The reason is
> > > B signed QoS agreement with A & C, but A & C may not have any, so
C
> > > won't prioritize the media traffic coming directly from A's IP
> peering
> > > interface. If the link is congested, the service quality will
> degrade.
> >
> > Implying there is an unneccessary Qos agreement in the core. As the
> > Scott
> > Marcus paper points out, this is unnecessary in most cases and
> > also not controllable. QoS, if at all, is only required in the
access.
> >
> > We should not waste our time with unimplementable issues.
> >
> > >
> > > I think peering is above policy. I assume that this WG will take
the
> > > lead to define and standardize the peering policy as well as the
> > > protocol distributing the policy.
> > >
> > > Yiu
> > >
> > >
> > > -----Original Message-----
> > > From: Hadriel Kaplan [mailto:[email-masked]]
> > > Sent: Sunday, April 02, 2006 9:48 PM
> > > To: 'Stastny Richard'; [email-masked]
> > > Subject: RE: [Speermint] Reachability
> > >
> > > Hi Richard, comments inline...
> > >
> > > > -----Original Message-----
> > > > From: Stastny Richard [mailto:[email-masked]]
> > > > Sent: Saturday, April 01, 2006 2:46 PM
> > > > To: [email-masked]
> > > > Subject: [Speermint] Reachability
> > > >
> > > > after reading the document from Scott Markus on NGN Interconnect
I
> > > > referenced for weekend reading in my last posting
> > > >
> >
http://www.itu.int/osg/spu/ngn/documents/Papers/Marcus-060323-Fin-v2.1
> > > > .pdf
> > >
> > > Indeed that was an interesting paper - thanks for the pointer!
(not
> > that
> > > I agree with everything in it)
> > >
> > > > and second we always started naturally at provider A in
direction
> of
> > > > call set-up and not at provider B
> > >
> > > Personally, I think the bigger "problem" is the provider C, the
one
> > > after B.
> > > :)  C trying to be reachable by A through B.  But that's out of
> scope
> > I
> > > guess.  It's too bad, because that's when BGP got interesting, for
> > > example.
> > >
> > > > Provider B has now (currently only for Public User Identities in
> the
> > > > form of E.164 numbers) the OBLIGATION making this PUI reachable
> for
> > > > the public by interconnecting with the public network (in this
> case
> > at
> > >
> > > > least via the PSTN) [snipped] So IMHO we can assume that
provider
> B
> > > > hosting a Public User Identity (a SIP URI) MUST make this PUI
> > > > reachable in principle.
> > >
> > > I would think that would only be true if you define the AoR to be
a
> > > public identity in the public domain, and such regulation was to
be
> > > created for AoRs.  E.164 numbers are by definition such numbers, I
> > > think.  But if, for example, I build a private enterprise network
-
> > > there's no way I'm obligated to do so just because I use the same
> SIP
> > > fields AoRs are used in.
> > >
> > > Having said that, I would think most providers _want_ to make them
> > > reachable, because that increases their value.  But as the paper
> > pointed
> > > out, peering is difficult to manage beyond a few hundred peers,
nor
> do
> > > IP or PSTN providers peer with everyone directly to achieve
> universal
> > > reachability.  That's why, for me, the more complex problem is the
> > > peer(s) between.  But documenting A-B/B-A is a good start.
> > >
> > > > The NRA normally sets the limits to such an offer.
> > >
> > > The power of the national rifle association is staggering.  ;)
> > >
> > > -hadriel
> > >
> > >
> > >
> > > _______________________________________________
> > > Speermint mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/speermint
> >
> > _______________________________________________
> > Speermint mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/speermint
> 
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint

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