Subject: RE: [Speermint] Basic Peering Requirements

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 19 Oct 2006 10:45:51 -0400

Brian,

Which would you rather maintain and advertise:

reachability to a hundred federations, or
reachability to millions of VSPs?

What you suggest doesn't scale.

The idea here was that once you know that a VSP belongs to a federation
(via ENUM and DNS), you are now looking for information that your
Transit VSP supports that federation and to which signaling address of
the Transit VSP to send the next signaling message.

Isn't that simpler?  Don't know why you want to make it harder.

There can be an address from which a federation membership can be
fetched, but I would rather be pointed to the answer, than scanning
through lengthy membership lists to discover relationships.  I think the
main value is in having a federation point to the Transit providers
serving a federation only.  That should be a much smaller list.  But,
that step would not be needed by the originating VSP if it already knows
what federations its own Transit VSP serves and the terminating
federation is on that list.

In summary, routing towards federations as an aggregation mechanism
rather than individual VSPs scales better.

Mike

> -----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]
> Subject: RE: [Speermint] Basic Peering Requirements
> 
> 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
> 
> > -----Original Message-----
> > 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
> > 
> > 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
> 

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

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 19 Oct 2006 12:29:03 -0400

Which scaling limits are you working from, PSTN or the Internet?  

Reachability to thousands (or tens of thousands, or a couple hundred
thousand) VSPs is what I want.

I want the "best" route to a VSP (which I may only know by a TN in a
registry). A federation is one potential route.

Scaling to tens or hundreds of thousands of routes is usually considered to
be quite reasonable, and even millions is quite reasonable for L5 routing
since we don't need to keep the routes in memory.  Certainly a federation
returning VSP reachability to that many VSPs is easy.

If all I have is one transit peer, and no federations, then I can launch my
call and if it doesn't work, all I can do is send it via the PSTN.  Same if
I am only a member of one federation.

As soon as I have two routes, I need to know where to send it for the next
hop.  I have the destination VSP, I choose a route: VSP in, route out.  I
check my routes for reachability.  If there is only one route, I send out
the call that way.  If I have more than one route, then I need a cost
metric, and we don't have to go there right now.  The point is that for each
route, what I want is the complete set of VSPs that route can get me to.

Seems like getting that information directly is the simplest way to go.

Brian

> Sent: Thursday, October 19, 2006 10:46 AM
> To: Brian Rosen; Stastny Richard; Otmar Lendl; Daryl Malas
> Cc: [email-masked]