Subject: RE: [Speermint] Reachability

From: "Medhavi Bhatia" <[email-masked]>
Date: Wed, 5 Apr 2006 20:55:58 -0400

Hi Peter,

In the A-B-C model, isn't B going to map to the IXP (or interconnect) as
discussed in the WG discussions?

-Medhavi.

> -----Original Message-----
> From: Peter Macaulay [mailto:[email-masked]]
> Sent: Wednesday, April 05, 2006 8:02 PM
> To: Lee, Yiu; [email-masked]
> Subject: RE: [Speermint] Reachability
> 
> Yiu Lee.  Thank you.  You have quickly taken us to the design
> issue: Does peering need to include the A-B-C model where A-C
> may have a trust relationship, but not A-B nor B-C?
> 
> So do we allow;
> 
>   (1) A-B-C peering signaling path with no media-relay (do your own)
>   (2) A-B-C peering signaling path with media-relay.
> 
> Variations will break some security models!  As Melampy says
> there will always be "networks between" -- so let's not avoid the
> real A-B-C world.  As mentioned earlier, solving the relay issue
> has been part of Skype's success.
> 
> /PETER MACAULAY
> 
> At 07:21 PM 4/5/2006, Lee, Yiu wrote:
> >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). 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. 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.
> >
> >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
> 
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.385 / Virus Database: 268.3.5/301 - Release Date:
4/4/2006

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