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

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

Tim,

By serving, I meant willingness to originate or terminate traffic
to/from that federation to other federations.

Mike

> -----Original Message-----
> From: Dwight, Timothy M (Tim) [mailto:[email-masked]] 
> Sent: Wednesday, September 20, 2006 12:59 PM
> To: Stastny Richard
> Cc: [email-masked]
> Subject: RE: [Speermint] Dear Collegues .. a modest proposal.
> 
> Thanks, Richard.  Other commFrom [email-masked] Thu Sep 21 18:09:39 2006
Content-class: urn:content-classes:message
Subject: RE: [Speermint] Dear Collegues .. a modest proposal.
Date: Thu, 21 Sep 2006 17:59:24 -0400
To: "Dwight, Timothy M \(Tim\)" <[email-masked]>,
	"Stastny Richard" <[email-masked]>

	        "Stastny Richard" <[email-masked]
	>; X=v=cisco.com; h=2IGC8vSmEfejlZ67emBbkjDVx6M=;
	b=HCuL2kHEzCxePsgimhzWIxqAkvn+fDzO23eGM3QfCzL3p7ut4HlihLteauG/b4kgyqJetE6f
	YZ6i5bKwD4z0LVHjJdPYHBvKcu3HqbhgrbeZZBTcSTiAr6t62ktCwPrj;
Cc: [email-masked]

Tim,

By serving, I meant willingness to originate or terminate traffic
to/from that federation to other federations.

Mike

> -----Original Message-----
> From: Dwight, Timothy M (Tim) [mailto:[email-masked]] 
> Sent: Wednesday, September 20, 2006 12:59 PM
> To: Stastny Richard
> Cc: [email-masked]
> Subject: RE: [Speermint] Dear Collegues .. a modest proposal.
> 
> Thanks, Richard.  Other comments inserted below.
> 
> tim
> 
> > >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.,).
> > 
> > 
> > The selection is always done by the originating VSP If both the 
> > originating VSP and the terminating VSP have more than one 
> federation 
> > in common, which means the originator may choose between 
> two or more 
> > NNIs. IMO it is then a local decision depending e.g on load 
> balancing 
> > or preferred NNI, etc. Weight, priorities etc from the destination 
> > side may not be helpful here
> 
> I assumed it would be up to the originating VSP, was just 
> wondering if there was value in letting the destination VSP 
> provide input into that decision.  I don't have a specific 
> use case in mind.
> 
> 
> 
> > 
> > >2. What does it mean for a transit SP to "serve a federation"?  
> > IMO there are (at least) two types of transit providers:
> >  
> > a. transit providers given by the terminating VSP this can easily 
> > handled by federation policy records as described in 
> > draft-lendl-speermint-federations with a nor-terminal NAPTR
> >  
> > you look up the ttermination domain and find te.g. wo
> > NAPTRs:
> > first is say an IPX federation
> > second is a national carriers federation
> >  
> > if you are not member of IPX,, you go for the non-terminal 
> pointing to 
> > a VSP which is also part of the national federation (e.g. the 
> > incumbent carrier) If you are also part of the national federation, 
> > you are done
> >  
> > b. you are a small operator an forward all traffic which does not 
> > belong to your federation to a well-established transit 
> operator, who 
> > cares about any traffic
> 
> I understand.  But in these examples (and in 
> draft-lendl-speermint-federations generally) the transit SP 
> seems to serve an individual VSP.  I'm still not sure in what 
> sense a transit provider serves 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)?
> >  
> > could be, but not necessarily
> >  
> > Richard
> > 
> > >tim
> > 
> > 
> > 
> > 
> 
> _______________________________________________
> 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: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Fri, 22 Sep 2006 05:44:14 +0000

> 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 
> will also help on QoS and manageability.

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.

> > > 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]
> [snip]

---

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

I understand.  I was just trying to tie this back to
draft-lendl-speermint-federations, in which transit VSPs are identified
by the destination VSP (section 4.3, step 2) not by the federation.
Conceptually I understand the notion that a VSP might offer such
services to whole federations, but I'm not clear how its willingness to
do so is discovered.

Tim

> Sent: Thursday, September 21, 2006 4:59 PM
> To: Dwight, Timothy M (Tim); Stastny Richard
> Cc: [email-masked]
> By serving, I meant willingness to originate or terminate 
> traffic to/from that federation to other federations.
> 
> Mike
>  
> 
> wondering if 
> > there was value in letting the destination VSP provide 
> input into that 
> > decision.  I don't have a specific use case in mind.
> > 
> > 
> > 
> > > 
>255fce80fa0b77fb2433
Cc: [email-masked]
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

I understand.  I was just trying to tie this back to
draft-lendl-speermint-federations, in which transit VSPs are identified
by the destination VSP (section 4.3, step 2) not by the federation.
Conceptually I understand the notion that a VSP might offer such
services to whole federations, but I'm not clear how its willingness to
do so is discovered.

Tim

> Sent: Thursday, September 21, 2006 4:59 PM
> To: Dwight, Timothy M (Tim); Stastny Richard
> Cc: [email-masked]
> By serving, I meant willingness to originate or terminate 
> traffic to/from that federation to other federations.
> 
> Mike
>  
> 
> wondering if 
> > there was value in letting the destination VSP provide 
> input into that 
> > decision.  I don't have a specific use case in mind.
> > 
> > 
> > 
> > >