Subject: RE: [Speermint] Dear Collegues .. a modest proposal.

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 21 Sep 2006 17:52:43 -0400

Inline.

Mike

> -----Original Message-----
> From: Dwight, Timothy M (Tim) [mailto:[email-masked]] 
> Sent: Wednesday, September 20, 2006 10:31 AM
> To: Michael Hammer (mhammer); [email-masked]; Stastny 
> Richard; Andrew Newton
> Cc: [email-masked]
> Subject: RE: [Speermint] Dear Collegues .. a modest proposal.
> 
> I'm confused by a couple of points.
> 
> 1. If a VSP can participate in many federations then it must be the 
>    case that the domain lookup sometimes finds multiple federations.
>    On what basis is a selection made, and does this require some
>    standardization (e.g., publication of weights, priorities, etc.,).

This was just recognizing that a VSP could be multi-homed.  If the
caller determines from the target's domain name that they can be reached
by multiple federations, then the question is whether one of those is
common to the caller's domain.  If it is, choose one, perhaps based on
caller's preference.

> 
> 2. What does it mean for a transit SP to "serve a federation"?  Are we
>    assuming some sort of federation-level interconnection (i.e., that
>    the transit SP interconnects "to the federation" rather than to
>    federation memebers)?

I was thinking that some members don't do transit while some offer
transit as a service.  Because not every called party will belong to the
same federation as a caller, there must be an intermediary, i.e. a
transit provider.  In that case, a transit provider serving both
federations could minimize the number of carriers involved and thus
dividing the pie.

But, there are likely cases where two transit carriers will be needed
because there is no transit VSP serving both originating and terminating
federations.  Thus, there must be two.  In that case, it would be a good
idea if many, if not all the transit VSPs had their own (transit)
federation.

For scalability, following just some basic assumptions, I came to the
conclusion that for many cases at least one, and often two transit VSPs
would be essential to get global L5 routability.  Conversely, there was
not much justification for going beyond the two.  I suspect that market
efficiencies will drive extra interlocutors out.  In the long run this
will also help on QoS and manageability.

Mike

> 
> tim
> 
> 
> > -----Original Message-----
> > From: Michael Hammer (mhammer) [mailto:[email-masked]]
> > Sent: Tuesday, September 19, 2006 2:21 PM
> > To: [email-masked]; Stastny Richard; Andrew Newton
> > Cc: [email-masked]
> > Subject: RE: [Speermint] Dear Collegues .. a modest proposal.

[snip]

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

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Fri, 22 Sep 2006 05:44:13 +0000

> I was thinking that some members don't do transit while some 
> offer transit as a service.  Because not every called party 
> will belong to the same federation as a caller, there must be 
> an intermediary, i.e. a transit provider.  In that case, a 
> transit provider serving both federations could minimize the 
> number of carriers involved and thus dividing the pie.

Sure.  I don't know how the transit provider's willingness to provide
such a service is discovered by the other federation members, though.
And I think that in addition to the willingness of a federation member
to serve in this capacity, there needs to be some means for the
destination VSP to influence the selection.

> 
> But, there are likely cases where two transit carriers From [email-masked] Fri Sep 22 01:49:28 2006
Date: Fri, 22 Sep 2006 05:44:13 +0000
From: "Dwight, Timothy M (Tim)" <[email-masked]>
Subject: RE: [Speermint] Dear Collegues .. a modest proposal.
To: "Michael Hammer (mhammer)" <[email-masked]>, [email-masked],
	Stastny Richard <[email-masked]>, Andrew Newton <[email-masked]>
Content-class: urn:content-classes:message
Cc: [email-masked]

> I was thinking that some members don't do transit while some 
> offer transit as a service.  Because not every called party 
> will belong to the same federation as a caller, there must be 
> an intermediary, i.e. a transit provider.  In that case, a 
> transit provider serving both federations could minimize the 
> number of carriers involved and thus dividing the pie.

Sure.  I don't know how the transit provider's willingness to provide
such a service is discovered by the other federation members, though.
And I think that in addition to the willingness of a federation member
to serve in this capacity, there needs to be some means for the
destination VSP to influence the selection.

> 
> But, there are likely cases where two transit carriers will 
> be needed because there is no transit VSP serving both 
> originating and terminating federations.  Thus, there must be 
> two.  In that case, it would be a good idea if many, if not 
> all the transit VSPs had their own (transit) federation.

I'm not sure what you mean by "transit federation".  Is that a special
kind of federation?  Who would be its members?  The transit VSP and all
the VSPs to whom the transit VSP provides [transit] service?  But, if
they're all in the same federation, they don't need transit service -
they can route to one another directly. 

> 
> For scalability, following just some basic assumptions, I 
> came to the conclusion that for many cases at least one, and 
> often two transit VSPs would be essential to get global L5 
> routability.  Conversely, there was not much justification 
> for going beyond the two.  I suspect that market efficiencies 
> will drive extra interlocutors out.  In the long run this 

It would IMHO be best to design mechanisms that allowed there to be 'N'
transit VSPs and then allow the market to determine the optimal value of
N.