Subject: RE: [Speermint] Basic Peering Requirements

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 18 Oct 2006 13:01:07 -0400

I had taken this to mean that the Transit VSP would be advertising to
originating VSPs reachability to various federations of the form:

(to get to)      (contact)
Federation X --> [email-masked]  (Fed-X etc. could be an arbitrary
string)
Federation Y --> [email-masked]
Federation Z --> [email-masked]
 
or:

Federation X --> [email-masked]
Federation Y --> [email-masked]
Federation Z --> [email-masked]

If not, count me as misunderstanding too.

Mike

> -----Original Message-----
> From: Stastny Richard [mailto:[email-masked]] 
> Sent: Wednesday, October 18, 2006 10:05 AM
> To: Otmar Lendl; Daryl Malas
> Cc: [email-masked]
> Subject: Re: [Speermint] Basic Peering Requirements
> 
> >> If a peer is providing connectivity to multiple federations, it 
> >> should disclose AoRs providing indirect peering relationships to 
> >> servicing peers or federations.
> 
> >Sorry, I don't understand that sentence.
> 
> >Do you mean that when a VSP adds an AoR to a federations routing 
> >database, then it needs to discluse whether that is a direct 
> customer 
> >or just a transit offer?
> 
> Sorry, but I do not understand the whole issue:
>  
> An AoR is a a special type of SIP URI (a Public User 
> Identity) defining the destination network (administrative domain)
>  
> How can it be disclosed or not, especially for a transit network?
> It is always public.
>  
> Richard
> 
> 
> ________________________________
> 
> Von: Otmar Lendl [mailto:[email-masked]]
> Gesendet: Mi 18.10.2006 15:54
> An: Daryl Malas
> Cc: [email-masked]
> Betreff: Re: [Speermint] Basic Peering Requirements
> 
> 
> 
> 
> Daryl,
> 
> > peering requirements from one operators perspective.  I can 
> post these 
> > to the list if you would like.  Here is a list of peering 
> requirements 
> > (this is certainly not exhaustive, but is a platform):
> 
> Here are my comments to that list:
> 
> General: this seems to be a list providing details on what 
> federations have to do (or agree on).
> 
> > Transport (Layer 1  3):
> >
> > Peering must utilize IP as the primary mechanism for peering.
> >
> > A federation must agree upon a common mechanism for IP transport 
> > either private (e.g. IPVPN, IPSEC, etc.) or public.
> 
> Fine.
> 
> > Billing:
> 
> Good.
> 
> > Policy:
> >
> 
> Could you be a bit more specific on what you mean by "policy" 
> in this context?
> 
> > Policies may be implemented locally to the peer or via a 
> centralized 
> > mechanism within the federation.
> >
> > Local policies should be disclosed when creating direct peering 
> > relationships with the applicable direct peer.
> >
> > Local policies may supersede centralized federation policies.
> >
> > (Net of this...some peering relationships will be 1:1, so policies 
> > will likely be local only.  Some peering relationships will 
> be 1:N, so 
> > policies will likely be implemented within DNS or some centralized
> > mechanism.)
> 
> Could you provide some examples of such policies?
> 
> > Membership:
> >
> > A peer may be a member of multiple federations
> >
> > A peer must maintain compliancy for policies as defined by each 
> > federation the peer is a member of.
> >
> > If a peer is providing connectivity to multiple 
> federations, it should 
> > disclose AoRs providing indirect peering relationships to servicing 
> > peers or federations.
> 
> Sorry, I don't understand that sentence.
> 
> Do you mean that when a VSP adds an AoR to a federations 
> routing database, then it needs to discluse whether that is a 
> direct customer or just a transit offer?
> 
> > Peers providing indirect peering must enforce federation 
> policies on 
> > behalf of the destination federation.
> >
> > A peer providing indirect peering may enforce undisclosed 
> policies for 
> > processing session requests between federations.
> >
> > (Net of this...some peers will only desire to be part of a single 
> > federation, where wholesale carriers will likely be members of 
> > multiple
> > federations.)
> 
> ok.
> 
> > Media:
> 
> ok.
> 
> > Routing:
> >
> > A peer must utilize the centralized federation routing 
> mechanism if it 
> > is available.
> 
> ok.
> 
> > A peer allowing another peer within a federation to provide 
> indirect 
> > peering on their behalf must select only one indirect peer to host 
> > their AoRs.
> 
> Do you mean indirect peering *within* a federation? Let me 
> name the parties here:
> 
> > A peer (X) allowing another peer (Y) within a federation (F1) to 
> > provide indirect peering on their behalf must select only 
> one indirect 
> > peer to host their AoRs.
> 
> Is the idea here that all members of F1 who want to place 
> calls to X need to route the calls via Y? In that case, I 
> would not consider X to be a member of F1. Instead, Y is 
> providing transit services for X.
> 
> Or you want to restrict X to be able to only select one other 
> VSP to host it's AoRs in total?
> 
> > A peer must not copy routing information from or make 
> assumed routing 
> > choices on behalf of the centralized routing mechanism for 
> use locally 
> > unless it takes place through standard caching methods.
> >
> > A common API must be utilized and available for subscriber 
> and route 
> > provisioning on any centralized federation location function.
> >
> > Subscriber and routing information must be dynamically 
> updated as soon 
> > as applicable for accurate routing within the federation.
> 
> ok
> 
> > Performance:
> >
> > Performance metrics must be shared between peers as they apply 
> > directly to peering signaling and media on a consistent 
> basis within 
> > the federation.
> 
> ok
> 
> /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

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 18 Oct 2006 13:54:36 -0400

To me, this is off the deep end.

I think we don't care what federations a destination network belongs to.
Sorry Otmar.

I think a federation may advertise what peers it can get you access to.
That may include transit peers, and those transit peers may get you to other
peers through other federations.  The federation advertises the aggregate of
what networks it can reach, direct or indirect.

I don't want a peer to have to keep relationships (how it gets to Fed X)
straight, I want it to be able to ask the federations or transit networks it
deals with if they have a route to the destination network.

If you take this view, then you always get what you want to know, regardless
of how convoluted the routes are, by simple queries to each
federation/transit network.  If you try to trace routes in advance (let's
see, I want to get to network A, he is part of Fed 1 and Fed 2, I'm not in
fed 1 or 2, hmmm, peer Z is part of fed 2 and he is also part of Fed 3, and
I'm in fed 3, so I can send it to Z via fed 3, and he can send to fed 2 to
get to A).

Much better if Fed 3 advertises it can reach A.

This is how route advertisements work, and I think we should assume that's
the best way until proven otherwise.

So let's not talk about Federations a network belongs to, and specifically,
don't talk about routes TO A FEDERATION, but rather routes to a destination
network FROM a federation.

Brian

> From: Michael Hammer (mhammer) [mailto:[email-masked]]
> Sent: Wednesday, October 18, 2006 1:01 PM
> To: Stastny Richard; Otmar Lendl; Daryl Malas
> Cc: [email-masked]
> Subject: RE: [Speermint] Basic Peering Requirements
>

---

From: "Pfautz, Penn L, GBLAM" <[email-masked]>
Date: Wed, 18 Oct 2006 14:06:21 -0400

So, how does a Federation "advertise"? I hope we're not talking about
building something TRIP-like.
Route advertisements may be the best way for IP routing but it's not a
slam dunk that they fit here.
That was the wrong answer for E.164, for example, because the address
space had different properties.

Penn

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, October 18, 2006 1:55 PM
To: 'Michael Hammer (mhammer)'; 'Stastny Richard'; 'Otmar Lendl'; 'Daryl
Malas'
Cc: [email-masked]

I think a federation may advertise what peers it can get you access to.
That may include transit peers, and those transit peers may get you to
other
peers through other federations.  The federation advertises the
aggregate of
what networks it can reach, direct or indirect.

I don't want a peer to have to keep relationships (how it gets to Fed X)
straight, I want it to be able to ask the federations or transit
networks it
deals with if they have a route to the destination network.

If you take this view, then you always get what you want to know,
regardless
of how convoluted the routes are, by simple queries to each
federation/transit network.  If you try to trace routes in advance
(let's
see, I want to get to network A, he is part of Fed 1 and Fed 2, I'm not
in
fed 1 or 2, hmmm, peer Z is part of fed 2 and he is also part of Fed 3,
and
I'm in fed 3, so I can send it to Z via fed 3, and he can send to fed 2
to
get to A).

This is how route advertisements work, and I think we should assume
that's
the best way until proven otherwise.

So let's not talk about Federations a network belongs to, and
specifically,
don't talk about routes TO A FEDERATION, but rather routes to a
destination
network FROM a federation.

Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 18 Oct 2006 14:40:15 -0400

In most federations today, "advertisement" is in the registry; all of the
reachable numbers are in the registry.  That may not work for everyone, and
we may need a mechanism that is two step (look up number to get network, and
then federations have lists of networks they can reach).  You probably
combine that step with the "which ingress point" lookup, so it's
number@domain query and it yields number@fqdn entry or an error.
Federations that maintain full registries would make that a single query
(number or number@localdomain in, number@fqdn out).  Of course "number"
could be "user".

I think it's manually maintained, and it's a simple table (list of domains
reachable by this federation).  When a peer is added or deleted, or that
peer, if it's a transit peer, makes new arrangements, then the list changes.

Due to actual agreements, I suspect that list is querier dependent (that is,
the federation may not have full symmetry of peering, and transit networks
may not be able to offer transit from any peer to any indirect peer).
That's a local matter for the federation, if it allows such arrangements.

Brian

> From: Pfautz, Penn L, GBLAM [mailto:[email-masked]]
> Sent: Wednesday, October 18, 2006 2:06 PM
> To: Brian Rosen
> Cc: [email-masked]

---

From: Otmar Lendl <[email-masked]>
Date: Wed, 18 Oct 2006 23:13:12 +0200

> I think we don't care what federations a destination network belongs to.

Sorry Brian, but it seems like you're approaching that problem with a 
telco mind-set that doesn't keep in mind the scale we get to once
SIP domain use reaches the same level as email domain use.

In SIP terms, destination network equals domain in the SIP AoR. As I
tried to get across at the interim meeting: The potential number of
different destination domains (= SIP networks) is *huge*. If we ever
manage to move from E.164 based addressing to SIP AoR based one, then
user-owned domains will replace number-portability and thus the number
of domain in play for SIP will skyrocket.

> I think a federation may advertise what peers it can get you access to.

Note that a federation in its simplest form is just a mathematical set
of VSPs which agree to a full mesh peering setup amongst themselves.
The assumption that there is some entity which acts as the manager of
that federation is just that: an assumption. That may be the case for
certain real-life federations (think xconnect), but that not a given at
all.

Anyway,

if "what peers" equals "what domains", then we're already off the deep
end here. The equivalent in the email space would be if all SMTP servers
tell their neighbors what domains they serve.

This just does not scale. 

> what networks it can reach, direct or indirect.

Just turn the thing around: Peers advertise to each other which
federations they can reach (meaning all members of those federations)
and to which they are willing to provide transit to.

What do we gain by this inversion?

* VSPs are the players in the game which define for themselves what
  service they provide to whom. 
  
  I just don't see the need to invent intermediaries for a role
  that the VSPs can play themselves.

* We reduce the size of the routing table by several orders of 
  magnitude. The set of federations will probably scale roughly with
  the number of commercial VSP + non-commercial peering arrangements.

  We're thus now in the range of where we are with AS numbers in BGP
  routing, instead of the number of domains active in email routing.

The only cost we incur for this reduced complexity is one single
lookup on the destination domain. (Whose results we need anyway if
we do RFC 3263 NAPTR parsing.)

> deals with if they have a route to the destination network.

Have a look at BGP: Who aggregates the routes learned there? Some
external company who manages the peerings for the ISP and which feeds the
forwarding table to the routers or isn't that a function that the ISP very
much wants to control himself?

Oh yes, sometimes an Internet Exchange operates a BGP route server
to help its members with the peering, but let's be realistic: 99% of the
Internet traffic doesn't need such services. Why do you think we need
that for SIP? Just because that's the way it's currently done in the
NANP PSTN?

[...]

> network FROM a federation.

Sorry, no deal. Why do you want to make the system more complex and
invent external actors which are not needed in the simple one?

/ol

---

From: Klaus Darilion <[email-masked]>
Date: Fri, 20 Oct 2006 13:22:44 +0200

> I think we don't care what federations a destination network belongs to.
           ^^
           we?

Maybe you do not care. But there are people who care about the 
federation of a destination network.

> what networks it can reach, direct or indirect.

In a steady state, the aggregate will be all VSPs in the world. That 
sounds like you want BGP for SIP - make sure not to forget loop detection.

IMO a federation should only advertise federation members. If one of the 
federation members is also a transit provider, it should not be the task 
of the federation to collect all transit routes and announce them to the 
  peers.

Otherwise I do not really see the need of federations.

> straight, I want it to be able to ask the federations or transit networks it

Who will you ask? The federation or the transit networks? If the transit 
providers are also in federations, what is the difference between a 
transist network and a federation network which offers transit too?

> I'm in fed 3, so I can send it to Z via fed 3, and he can send to fed 2 to

Of course it won't be that easy as peer 2 will charge different costs 
(or require additional transit contracts) if it terminates a call or 
forward it.

> network FROM a federation.

Again. If the federations are irrelevant - for what purpose do you still 
need them?

regards
klaus

-- 
Klaus Darilion
nic.at