Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

From: "Malas, Daryl" <[email-masked]>
Date: Tue, 30 May 2006 15:43:00 -0600

I was thinking in terms of Contradiction 2 (if I'm reading your list
correctly)...B won't tell A about it's routes to C and D, because B has
negotiated a "private" relationship with A. In this case, A can only
route to B (and D via it's other "private" relationship).  In this case,
I am not describing a transit scenario with B.  B simply has multiple
peering relationships with varying types of peering partners (public or
open vs. private).  Now please don't confuse the internet as implying a
public peering relationship, although that is what I intended for this
example.  The internet is simply a layer 3 mechanism, and a private
peering relationship could exist via that path as well.

Peering can and should be architected to work in a transit scenario as
well, as you began to describe below.  A peers with B, because it knows
B is peered with many federations or domains.  In this case, B is acting
as a transit or termination peering hub to multiple spokes (if I can use
that analogy liberally) -- B may also have domains associated with it.
Also, A could still maintain a private peering relationship with D, to
create multiple layer 5 path choices for getting to D.  For example, D
may be peered with a DS-3 with high levels of quality (e.g. diffserv,
ToS, etc.), while the peering relationship to B may be an OC-12 without
quality guarantees.  A's primary choice to D is via it's private peering
relationship to D, and a secondary choice is through B.

This is getting fairly complex, but all of these are good to hash out in
the architecture document...otherwise, the industry will run with crazy
one-offs in every different direction causing incompatibilities on
several levels.

--Daryl

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, May 30, 2006 3:03 PM
To: 'Pfautz, Penn L, GBLAM'; Malas, Daryl; 'Otmar Lendl';
[email-masked]
Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

Perhaps we are misinterpreting the figure.  I am interpreting C as
accepting
calls over the Internet from any domain (that is, not limited to
specific
peers).  I'm not just thinking that the peering fabric is the Internet;
of
course any connection between peers can traverse the Internet.  I assume
A
knows it wants a route to C.  ENUM is out of scope.  The Route
Advertisement
is what domains B tells A it can get to, so that A knows B can get to C.

Contradiction 1 is that if C is known to accept connections from any
domain,
then B is not adding value.  It can't be a secret only known to B that C
accepts any connections.

Contradiction 2 is that B can't tell A that it can reach all possible
C's.
A specific C, maybe, but then you are back to Contradiction 1.

Let's be more concrete.  Suppose there is an enterprise with a SIP PBX.
Suppose it starts out by purchasing VoIP termination services from a
carrier
and sends all its traffic there, and to start, only accepts traffic from
its
carrier.   Now, suppose that at some point the enterprise gets
comfortable
and starts allowing traffic from the Internet direct to its PBX.
Suppose,
just to get it off the table, that there is public ENUM, so number
services
are not an issue.

This enterprise is now a "C".  How does B tell A that it can get to C?
How
does it know that?

Generally, C freely "advertises" its "route" by simply putting an SRV
record
in its public DNS.  What is the way A "seeks a route to C" by any
mechanism
short of just trying DNS.  What I'm getting at is that B can't make a
definitive list of all the C's out there, and there is no wildcard that
works.   

Brian

-----Original Message-----
From: Pfautz, Penn L, GBLAM [mailto:[email-masked]] 
Sent: Tuesday, May 30, 2006 4:20 PM
To: Brian Rosen; Malas, Daryl; Otmar Lendl; [email-masked]
Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

Sorry, sent too soon...
This is the kind of thing that makes we wonder why anyone wants to look
at this in terms of route advertisement where A doesn't know the
destination is C and just looks at what B says it can reach. I can
imagine that A knows the ultimate destination is C and then seeks a
route to C, which would eliminate the contradictions Brian raises.

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, May 30, 2006 4:02 PM
To: 'Malas, Daryl'; 'Otmar Lendl'; [email-masked]
Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

I am absolutely certain that these kinds of arrangements will be seen
"in
the wild".  Two thoughts strike me:
1) If Domain A is paying Domain B a lot for this kind of service, it may
need a software update so it can do it itself
2) The route advertisement from B towards A gets REALLY tricky.  The
reason
is that there is no convenient way to express it.  It's not "*" (I can
get
you to any domain).  It's "I can get you to any domain that accepts
connections from the Internet".  It's the terminating network that
decides
if it will allow traffic from some other domain, and "Domain B" below,
doesn't know what the rules for Domain C are.

Brian

-----Original Message-----
From: Malas, Daryl [mailto:[email-masked]] 
Sent: Tuesday, May 30, 2006 3:45 PM
To: Otmar Lendl; [email-masked]
Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

In addition to your comments below, I think peering will likely occur in
one of the following methods or all of them (this includes the
capabilities described in the Peering Architecture Draft:

+---------+
                                                           |         |
+--------+         +--------+           +------------+    /|Domain C | 
|        |		 |        |          /              \  / |
|
|Domain A| Private |Domain B| Public  |    Internet    |/  +---------+
|        |=========|        |=========|                |\
|        |  Peer   |        |  Peer    \              /  \ +---------+
+--------+         +--------+           +------------+    \|         |
    ||
|Domain D |	
    =======================================================|         |	
				Private Peer
+---------+

As far as PBX interconnect goes...

I don't think SPEERMINT should design a tie-line replacement
architecture.  IMO, it is out of scope.  I know this becomes somewhat
blurry, as more SIP PBX's are a conglomeration of multiple SIP
capabilities (e.g. UA, UAS, Proxy, etc.), some of which are described in
the architecture.  However, the SIP Forum is already addressing many of
those concerns in SIP Forum drafts such as:
sf-draft-twg-IP_PBX_SP_Interop-sibley-v5.pdf.

My two cents...

--Daryl M.

-----Original Message-----
From: Otmar Lendl [mailto:[email-masked]] 
Sent: Tuesday, May 30, 2006 11:51 AM
To: [email-masked]
Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture

On 2006/05/30 19:05, "Livingood, Jason"
<[email-masked]> wrote:
> > I believe this discussion has gone over the edge.
> > 
> > The reason SPEERMINT exists is that CARRIERS want to peer.
> 
> Perhaps a fair assessment, but I suspect we all would like it to
> progress beyond that.  
>  
> > Email is an inappropriate metaphor for carrier peering.
> 
> Perhaps but I don't think we can conclude that as yet.  There are most
> definitely differences though.  I see no reason not to try to take
some
> of the simplicity and ubiquity of that model and trying to apply it to
a
> new application where it makes sense.

My take is that we need a system that

* allows selective peering. If we require that everybody can talk
  directly to everybody else, we don't get carrier opt-in.

* supports branching off into private interconnects.

  Ideally, all the existing private peering fabrics should fit
  into the speermint umbrella.

* scales to wide adoption, both for SIP URIs / domains as well as
  peering operators.

  Nothing in the protocol should preclude that it is used e.g.
  to get VoIP-enabled PBX systems to peer with each other.

  (Whether a carrier wants to peer with a PBX is his choice. 
  The protocol shouldn't dictate a peering policy. The contrary:
  the protocol must support all possible peering policies.)

* gives BCPs on how to do the nitty-gritty SIP details
  (caller-ID, privacy, ...)

/ol
-- 
< Otmar Lendl ([email-masked]) | nic.at Systems Engineer >

_______________________________________________
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

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 30 May 2006 18:08:20 -0400

I misinterpreted your diagram.  I thought you were talking about public
"peering" on the Internet with B as a transit network.

Agree that any link between peers can be an Internet link.  I think it's not
helpful to show them in diagrams like this; it just confuses things.
Nothing is different except the packet path, and we don't care about that in
this WG.

Agree that if you have route advertisements, you can have multiple paths to
the same termination and you need a "cost" metric to choose.  Standard
stuff, and I hope we aren't planning to go overboard on the "cost" metric.

Transit is independent from multiple paths.  I could easily see B being part
of multiple peering federations, where, say D is in more than one of them
also, so B has at least two paths to D with no transit networks.  Transit is
path aggregation (A can get to B, B can get to D, so A can get to both B and
D via the same path).

Brian

-----Original Message-----
From: Malas, Daryl [mailto:[email-masked]] 
Sent: Tuesday, May 30, 2006 5:43 PM
To: Brian Rosen; Pfautz, Penn L, GBLAM; Otmar Lendl; [email-masked]
Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

--Daryl

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, May 30, 2006 3:03 PM
To: 'Pfautz, Penn L, GBLAM'; Malas, Daryl; 'Otmar Lendl';
[email-masked]

Brian

-----Original Message-----
From: Pfautz, Penn L, GBLAM [mailto:[email-masked]] 
Sent: Tuesday, May 30, 2006 4:20 PM
To: Brian Rosen; Malas, Daryl; Otmar Lendl; [email-masked]
Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

Sorry, sent too soon...

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, May 30, 2006 4:02 PM
To: 'Malas, Daryl'; 'Otmar Lendl'; [email-masked]
Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

Brian

-----Original Message-----
From: Malas, Daryl [mailto:[email-masked]] 
Sent: Tuesday, May 30, 2006 3:45 PM
To: Otmar Lendl; [email-masked]
Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

+---------+
                                                           |         |

My two cents...

--Daryl M.

-----Original Message-----
From: Otmar Lendl [mailto:[email-masked]] 
Sent: Tuesday, May 30, 2006 11:51 AM
To: [email-masked]
Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture

some
a

/ol