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

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 19 Sep 2006 14:59:27 -0400

I have no problem with the idea of prioritizing/phasing the work.

Mike

> -----Original Message-----
> From: Richard Shockey [mailto:[email-masked]] 
> Sent: Tuesday, September 19, 2006 1:11 PM
> To: Michael Hammer (mhammer); [email-masked]
> Subject: RE: [Speermint] Dear Collegues .. a modest proposal.
> 
> 
> 
> > -----Original Message-----
> > From: Michael Hammer (mhammer) [mailto:[email-masked]]
> > Sent: Tuesday, September 19, 2006 12:32 PM
> > To: [email-masked]; [email-masked]
> > Subject: RE: [Speermint] Dear Collegues .. a modest proposal.
> > 
> > Richard,
> > 
> > I think the identification of belonging to a federation is not that 
> > complex and greatly simplifies discovering if one can route 
> directly 
> > or must route indirectly through a transit SP.  Thus, I do 
> not agree 
> > with lumping that in with Policy as too complex to do now.
> 
> 
> OK ... that's a fair point certainly negotiable.but what 
> about the general principal of a SPEERMING SNIP profile as a 
> direction forward?
> 
> 
> > 
> > Mike
> > 
> > 
> > > -----Original Message-----
> > > From: Richard Shockey [mailto:[email-masked]]
> > > Sent: Tuesday, September 19, 2006 9:38 AM
> > > To: [email-masked]
> > > Subject: [Speermint] Dear Collegues .. a modest proposal.
> > >
> > >
> > >
> > > Sorry I'm not in Philadelphia but I want to propose a 
> concept for a 
> > > work plan that I hope can move us to some level of success in the 
> > > upcoming weeks.
> > >
> > > This is only a general proposal for discussion not a specific ID 
> > > ..yet.
> > >
> > > I'm afraid we have been attempting to boil the ocean here 
> when some 
> > > of us are looking for a simple 3 minute egg to begin with.
> > >
> > > The entire concept of a SIP based NNI is a very complex one that 
> > > will require lots of protocol elements over time but I sense a 
> > > strong desire among some to come to some consensus on a 
> relatively 
> > > simple base line that service providers can use now to "go to 
> > > market"  in anticipation of further IETF standards development in 
> > > the future.
> > >
> > > My concerns are more tactical than architectural.
> > >
> > > Though the Requirements document should document all of 
> the relevant 
> > > elements for a complete end to end solution it may not be 
> possible 
> > > to implement each and every proposed element in a timely manner.
> > >
> > > What I propose the WG do is attempt to organize the work into a 
> > > series of ..for lack of a better word ..Profiles, 
> buckets, baskets 
> > > or perhaps even Versions.  The concept would that the WG select a 
> > > series of the underlying requirements and organize them into a 
> > > coherent profile that implementers can readily understand 
> and deploy 
> > > now.
> > >
> > > All of us are well aware of the ongoing difficulties implementers 
> > > have in dealing with SIP in general. The IETF has a 
> hundred or more 
> > > RFC's, and countless ID's in one stage of development or another.
> > >
> > > Each and every one of us has heard the howls from time to time of 
> > > developers saying "Well where do I start? Which of these RFC do I 
> > > need to implement now?"
> > >
> > > I propose this profile be called the Simple Network 
> Interconnection 
> > > Profile ( SNIP )
> > >
> > > Some of the core issues IMHO have been well stated in
> > >
> > > draft-mahy-speermint-direct-peering-00.txt
> > >
> > > IMHO we can only achieve progress if we simplify the 
> scope of what 
> > > can be done in a reasonable amount of time.
> > >
> > > The core SNIP protocols should define.
> > >
> > > A. Discovery.
> > > Elements:
> > > 1. Pick your flavor of ENUM
> > > 2. Local SIP Location server or ENUM Cache.
> > >
> > >
> > > B. Authentication and Authorization
> > > Elements:
> > > 1 Big Yellow wire
> > > 2. IP SEC and other tunneling technologies 3. TLS
> > >
> > >
> > > C. Transaction Identity ( aka billing )
> > >
> > > As much as I would wish that we see adoption of
> > >
> > > http://www.rfc-editor.org/rfc/rfc4474.txt
> > >
> > > as soon as practically possible its going to take some time for 
> > > operators and suppliers to adopt hence there is still 
> some need for 
> > > some use of P-Asserted until such time as 4474 can be adopted.
> > >
> > > D. Minimum codec's
> > >
> > > Personally I've vacillated on this but it seems reasonable that a 
> > > minimum set be adopted.
> > >
> > > Everything else is assumed to be out of band and essentially 
> > > bi-lateral.
> > >
> > >
> > > If this seems a little like what has been proposed in the 
> SIPForum 
> > > SIPConnect specification I certainly apologize. I believe 
> there are 
> > > similarities in the problem statements between IP-PBX to 
> SP and SP 
> > > to SP NNI.
> > >
> > > If I seem obsessed with what we did with SIPConnect I 
> apologize but 
> > > I think it is worth offering as a point of discussion.
> > >
> > > What we cant do ... right now.
> > >
> > > A. Congestion.
> > >
> > > Realistically we cannot deal with issues such as network 
> congestion 
> > > awareness right now. Other IETF BOF's are starting to 
> look at this 
> > > issue.
> > > (see below)
> > >
> > > B. Federation Discovery and Policy. How you find a 
> federation what 
> > > are the policies associated with that federation.
> > >
> > > Its just too complex to believe that we can deliver a 
> solution in a 
> > > reasonable amount of time when we have not begun to outline the 
> > > semantics of what that policy should look like.
> > >
> > > C. Full Attribute based Identity Management across 
> transit networks.
> > >
> > > Again the issue is tactical vs architectural.
> > >
> > > Thoughts and flames are sincerely appreciated.
> > >
> > >
> > > --------------------------------------------------------------
> > > --------------
> > > ----
> > > From: Anna Charny (acharny)
> > > Sent: Thursday, September 14, 2006 4:51 PM
> > > To: 'Magnus Westerlund'; 'Lars Eggert'
> > > Cc: [email-masked]'; [email-masked]
> > > Subject: Request for Pre-Congestion Notification BOF
> > >
> > >
> > > Hello Lars and Magnus,
> > >
> > > This message constitutes a formal request for Pre-Congestion 
> > > Notification BOF at the November IETF meeting in San Diego.
> > >
> > > The BOF description and its proposed agenda are attached 
> at the end 
> > > of this message.
> > >
> > > If this BOF is approved,  we would like to request a 
> two-hour slot 
> > > that avoids scheduling conflicts with the following working
> > > groups:  tsv, nsis,
> > > sip, ieprep, ecrit, pwe3, dccp.
> > >
> > > We also ask that you CC [email-masked] with your decision.
> > >
> > > Of course we welcome any feedback you might have.
> > >
> > > Best Regards,
> > > Anna Charny
> > >
> > > PCN BOF Description
> > >
> > > The Pre-Congestion Notification (PCN)  BOF will address 
> the problem 
> > > of how to provide scalable and resilient admission control and 
> > > strong QoS assurance while using packet marking 
> techniques. Current 
> > > attempts to deliver QoS using only packet marking (e.g. DiffServ) 
> > > are limited in the level of QoS assurance that can be provided 
> > > without substantial over-provisioning. To improve the QoS 
> assurance, 
> > > PCN will add flow admission control and flow pre-emption. 
> In normal 
> > > circumstances admission control should protect the QoS of 
> previously 
> > > admitted flows. In times of heavy congestion (for example 
> caused by 
> > > route changes due to link or router failure) pre-emption of some 
> > > flows should preserve the QoS of remaining flows.
> > >
> > > The overall approach will be based on a the concept of a 
> PCN-Region, 
> > > within which the functionality is separated between the 
> PCN-Interior 
> > > Node (PIN) and the PCN-End Node (PEN). The initial scope 
> of the BOF 
> > > will be the case of a
> > > single DiffServ region, which maps to a PCN-Region.   
> PINs mark packet
> > > headers when their traffic is above a certain level, as an early 
> > > warning of incipient congestion ("pre-congestion"); this 
> builds on 
> > > concepts from RFC
> > > 3168 "The Addition of Explicit Congestion Notification to 
> IP".  PENs 
> > > monitor the markings and that information is used to make flow 
> > > admission control and pre-emption decisions. The 
> decisions could be 
> > > made by the PENs or by a centralized system (which is informed of 
> > > the PCN information).
> > >
> > > The BOF will address the need and the motivation for PCN 
> work in the 
> > > context of IETF, provide a brief overview of prior PCN 
> efforts and 
> > > related work, and review open issues.  The BOF will also 
> discuss the 
> > > scope of work and solicit feedback on the proposed charter.  
> > > Ultimately, the goal of the BOF is to solicit community 
> feedback on 
> > > whether the problem is clear and needs to be addressed, and 
> > > consequently whether the creation of a new PCN WG within 
> the scope 
> > > of the proposed charter is warranted.
> > >
> > > The draft charter is available from
> > > http://standards.nortel.com/pcn/PCN_draft_charter_v00.txt.
> > > The problem
> > > statement and motivation for the PCN work is discussed in more 
> > > detail in draft-chan-pcn-problem-statement-00, which has been 
> > > submitted to IETF and is also available at 
> > > http://standards.nortel.com/pcn/draft-chan-pcn-problem-stateme
> > > nt-00.txt.
> > >
> > > Proposed BOF agenda
> > >
> > > 1.  Agenda bashing  (5 min)
> > > 2.  Motivation and Problem Statement presentation  (15 min) 3.  
> > > Discussion of motivation and problem statement (30 min) 
> 4.  Overview 
> > > of prior PCN efforts, related work and open issues (15 min) 5.  
> > > Overview of the proposed charter (10 min) 6.  
> Discussion/bashing of 
> > > the proposed charter (20 min) 7.  General discussion and 
> poll on the 
> > > WG creation (25 min)
> > >
> > >
> > > Richard Shockey
> > > Director, Member of the Technical Staff NeuStar 46000 Center Oak 
> > > Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org 
> > > sip:5651(at)neustarlab.biz PSTN Office +1 571.434.5651 
> PSTN Mobile: 
> > > +1 703.593.2683 <mailto:richard(at)shockey.us> 
> > > <mailto:richard.shockey(at)neustar.biz>
> > >
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > 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: "Eli Katz" <[email-masked]>
Date: Wed, 20 Sep 2006 14:09:00 +0100

Correct; where all registry data is in one DB. 
 
However, this is not always the case, and will depend on different
federation and member data policies, re: full access to data (hence
pushed into one DB) vs query-only access to data.
 
And agreed, of course, the optimal query mechnism is 3761.
 
Eli

________________________________

From: Richard Shockey [mailto:[email-masked]] 
Sent: 20 September 2006 12:08
To: Eli Katz; 'Shawn Pouliotte'; 'Uzelac, Adam'; 'Brian Rosen'; 'Klaus
Darilion'
Cc: [email-masked]
Subject: RE: [Speermint] Dear Collegues .. a modest proposal.

I don't agree... any SP will logically look at his multiple peering
agreements and federation member ships and aggregate them into a single
optimal query response based on internal policy.

The optimal goal is all call querie on call origination.  One DB dip
does it all. Of course the optimal query mechanism is 3761.

No one is going to tolerate N queries to get an optimal routing /
termination path.

________________________________

From: Eli Katz [mailto:[email-masked]] 
Sent: Wednesday, September 20, 2006 6:37 AM
To: Shawn Pouliotte; Uzelac, Adam; Brian Rosen; Klaus Darilion;
[email-masked]
Cc: [email-masked]
Subject: RE: [Speermint] Dear Collegues .. a modest proposal.

re: simultaneous querying; In agreement with Shawn,

As there are a) a number of federation enum registries in existence
today, some with full data push, and others with query only, and b)
carriers/SPs are looking 1) to optimise the searching (i.e reduce PDD)
and 2) maximise the hit rate, therefore by enabling simultaneous queries
(with carefully selected "ms" timeouts) or a combination of sequential
and simultaneous, and a simple decision tree for multiple results,
allows the 2 key objectives to be achieved.

Afaik, even with alternative federation discovery mechanisms (Otmar et
al), any SP can be a member of multiple federations, in which case
again, the route-decision-process may involve multiple queries coupled
with a desire for optimum and efficient query logic.

Eli

________________________________

From: Shawn Pouliotte [mailto:[email-masked]] 
Sent: 20 September 2006 06:50
To: Uzelac, Adam; Brian Rosen; Klaus Darilion; [email-masked]
Cc: [email-masked]
Subject: RE: [Speermint] Dear Collegues .. a modest proposal.

Hi Adam,

I am curious why you would say that. Obviously I understand the issues
with serial queries and PDD but simultaneous? I fail to see the issue
unless its related to equipment capability. I see an incredible amount
of drive for simultaneous queries in numerous carriers. The carriers in
question generally prefer to peer and slave one another's data however
in some cases, some peering entities choose to not share the data and
will only support per call queries issued to their database. In these
cases, the operators are asking for; 

- Query off board databases if my local database does not have
resolution
- Query my database and all remote databases. 

The responses are then prioritzed and filters based on the carrier's
policy and the result is returned to the client/resolver. 

So, what is the concern? 

Thanks
Shawn

________________________________

From: "Uzelac, Adam" [mailto:[email-masked]]
To: Brian Rosen [mailto:[email-masked]], Klaus Darilion
[mailto:[email-masked]], [email-masked]
Cc: [email-masked]
Sent: Tue, 19 Sep 2006 18:53:41 -0700
Subject: RE: [Speermint] Dear Collegues .. a modest proposal.

I, for one, would never expect to see in our network a next-hop
determination process that would result from simultaneous dips.
Sequential dips could be something that I could handle, but my concern
there is primarily post-dial-delay. The ideal is a single
query/response for next-hop determination, and after that, sequential.
I am not a fan of the simultaneous dip scenario.

-AU

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, September 19, 2006 1:34 PM
To: 'Klaus Darilion'; [email-masked]
Cc: [email-masked]
Subject: RE: [Speermint] Dear Collegues .. a modest proposal.

This solution makes an assumption that as we currently see the market
evolving, doesn't make it practical FOR THE EARLY 'PROFILES'/'VERSIONS'

Specifically, the way we are actually (in every case I know) coupling
the enum dip with the federation.

This means you can't do federation discovery.

At some point, you could see these functions being split, and then it
becomes practical to do federation discovery.

Some people here have pointed out that if you go to a federation, get
the dip, and discover the identity of the terminating domain from the
dip, then you could connect via some other mechanism (private peering
for example).
Ignoring the business issues, you would have to do serious host name
hacking to actually do this. I can't see developing IETF specs on that
basis.

I'm trying to be practical here. Self serving, perhaps, but practical
none the less. I don't want to be spinning wheels developing specs that
can't actually be deployed real soon. As a practical matter, you CAN be
a member of multiple federations, and do simultaneous or sequential dips
in all of them, evaluate the results, and choose one. That is a form of
federation discovery, but it wouldn't use a mechanism like what Otmar
proposes.

Brian

> From: Klaus Darilion [mailto:[email-masked]]
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Speermint] Dear Collegues .. a modest proposal.
> 
> Hi Richard!
> 
> 
> 
> Richard Shockey wrote:
> >
> ...
> > B. Federation Discovery and Policy. How you find a federation what 
> > are
> the
> > policies associated with that federation.
> >
> > Its just too complex to believe that we can deliver a solution in a 
> IMO we are some further. There are already drafts (Otmar's drafts) 
> which describe how the federation discovery can be done (there is even

> working code available).
> 
> And the policy will be written on paper somewhere - like with current 
> interconnect agreements on TDM basis.
> 
> I agree with your other statements.
> 
> regards
> klaus
> 
> 
> >
> > C. Full Attribute based Identity Management across transit networks.
> >
> > --------------------------------------------------------------------
> > ----
> ----
> > ----
> Notification
> > BOF at the November IETF meeting in San Diego.
> >
> > The BOF description and its proposed agenda are attached at the end 
> > of
> this
> > message.
> >
> > If this BOF is approved, we would like to request a two-hour slot 
> > that avoids scheduling conflicts with the following working groups:

> > tsv,
> nsis,
> > The Pre-Congestion Notification (PCN) BOF will address the problem 
> > of
> how
> > to provide scalable and resilient admission control and strong QoS
> assurance
> > while using packet marking techniques. Current attempts to deliver 
> > QoS
> using
> > only packet marking (e.g. DiffServ) are limited in the level of QoS 
> > assurance that can be provided without substantial 
> > over-provisioning. To improve the QoS assurance, PCN will add flow 
> > admission control and flow pre-emption. In normal circumstances 
> > admission control should protect
> the
> > QoS of previously admitted flows. In times of heavy congestion (for
> example
> > caused by route changes due to link or router failure) pre-emption 
> > of
> some
> > The overall approach will be based on a the concept of a PCN-Region,
> within
> > which the functionality is separated between the PCN-Interior Node 
> > (PIN)
> and
> > the PCN-End Node (PEN). The initial scope of the BOF will be the 
> > case of
> a
> > single DiffServ region, which maps to a PCN-Region. PINs mark
packet
> > warning
> of
> > incipient congestion ("pre-congestion"); this builds on concepts 
> > from
> RFC
> > 3168 "The Addition of Explicit Congestion Notification to IP". PENs
> monitor
> > the markings and that information is used to make flow admission 
> > control
> and
> > pre-emption decisions. The decisions could be made by the PENs or by

> > a centralized system (which is informed of the PCN information).
> >
> > The BOF will address the need and the motivation for PCN work in the
> context
> > of IETF, provide a brief overview of prior PCN efforts and related 
> > work, and review open issues. The BOF will also discuss the scope 
> > of work and solicit feedback on the proposed charter. Ultimately, 
> > the goal of the
> BOF
> > is to solicit community feedback on whether the problem is clear and
> needs
> > to be addressed, and consequently whether the creation of a new PCN 
> > WG within the scope of the proposed charter is warranted.
> >
> > http://standards.nortel.com/pcn/PCN_draft_charter_v00.txt. The 
> > problem statement and motivation for the PCN work is discussed in 
> > more detail in draft-chan-pcn-problem-statement-00, which has been 
> > submitted to IETF
> and is
> > also available at
> >
http://standards.nortel.com/pcn/draft-chan-pcn-problem-statement-00.txt.
> > Discussion of motivation and problem statement (30 min) 4. Overview

> > Overview of the proposed charter (10 min) 6. Discussion/bashing of 
> > the proposed charter (20 min) 7. General discussion and poll on the

> > sip:5651(at)neustarlab.biz PSTN Office +1 571.434.5651 PSTN Mobile: 

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 21 Sep 2006 18:03:02 -0400

SIP: target user@VSP
Route: target Federation
?

Yes, very much analagous.

Mike 

> Sent: Wednesday, September 20, 2006 2:29 PM
> To: 'Dwight, Timothy M (Tim)'; Michael Hammer (mhammer); 
> 'Stastny Richard'; 'Andrew Newton'
> Cc: [email-masked]
> Let me try and set out an alternative theory of how this 
> might actually operate.
> 
> I agree that there is no way a SP is going to do look ups to 
> multiple databases, utter madness. What I presume operators 
> want is _one_ look up that provides a trusted set of data 
> that can be used to make a routing decision on based on local policy.
> 
> A service provider might be part of several federations 
> though in practice the administrative overhead of doing so 
> would be prohibitive. What some refer to as the N squared problem.
> 
> What is important is the SP be able to "publish" the 
> appropriate TN to URI mappings for their points of 
> interconnection for those end points that it purports to be 
> authoritative for to what I would define as a trusted private 
> registries that can act as data aggregator for multiple 
> service providers.
> 
> In the infrastructure ENUM system (ie164.arpa) this would be 
> the appropriate zone administrators' or  whomever the 
> national regulatory authority appoints.
> 
> The SP might asco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 21 Sep 2006 18:03:02 -0400
Content-class: urn:content-classes:message
Subject: RE: [Speermint] Dear Collegues .. a modest proposal.
Date: Thu, 21 Sep 2006 18:03:02 -0400
From: "Michael Hammer \(mhammer\)" <[email-masked]>
To: <[email-masked]>,
	"Dwight, Timothy M \(Tim\)" <[email-masked]>,
	"Stastny Richard" <[email-masked]>, "Andrew Newton" <[email-masked]>
	
        "
	Stastny Richard" <[email-masked]>,
	
       	20"Andrew Newton" <[email-masked]>;
	X=v=cisco.com; h=2IGC8vSmEfejlZ67emBbkjDVx6M=;
	b=hg40eMLLwhfBApzbOHUW6bNdz5C4eABOBUM5CRw4Im28iPgC/sCkNDvwHbPivTZUjZRii3AO
	+H0cfZJv65k9UasOvQ5nLaOB4Qrlbu/yXh9Bqk27auBnQ94DMJCOWSPn;
Cc: [email-masked]

SIP: target user@VSP
Route: target Federation
?

Yes, very much analagous.

Mike 

> Sent: Wednesday, September 20, 2006 2:29 PM
> To: 'Dwight, Timothy M (Tim)'; Michael Hammer (mhammer); 
> 'Stastny Richard'; 'Andrew Newton'
> Cc: [email-masked]
> Let me try and set out an alternative theory of how this 
> might actually operate.
> 
> I agree that there is no way a SP is going to do look ups to 
> multiple databases, utter madness. What I presume operators 
> want is _one_ look up that provides a trusted set of data 
> that can be used to make a routing decision on based on local policy.
> 
> A service provider might be part of several federations 
> though in practice the administrative overhead of doing so 
> would be prohibitive. What some refer to as the N squared problem.
> 
> What is important is the SP be able to "publish" the 
> appropriate TN to URI mappings for their points of 
> interconnection for those end points that it purports to be 
> authoritative for to what I would define as a trusted private 
> registries that can act as data aggregator for multiple 
> service providers.
> 
> In the infrastructure ENUM system (ie164.arpa) this would be 
> the appropriate zone administrators' or  whomever the 
> national regulatory authority appoints.
> 
> The SP might aggregate data directly from other trusted 
> private registries into a locally cached database or have 
> their registry operator aggregate data from multiple sources for them.
> 
> How the data is "published" is presumably some form of out of 
> band provisioning interface and how the registry data is 
> acquired is also out of band..for now.
> 
> That data is then made available in a "useful format" such as 
> DNS NAPTR records per 3761 and the SS or whatever network 
> elements then.  
> 
> Frankly for US Carriers none of this should come as a 
> surprise..the routing tables for the North American PSTN are 
> a union of the Telcordia Local Exchange Routing Guide and the 
> Number Portability Database Administration ..currently 
> NeuStar. Those trusted data sources are merged into a Service 
> Control Point which a Class 5 switch queries for authorative 
> routing data.
> 
> IMHO the solution is multiple data sources merged into a 
> single view for routing. Everything else is how does the SS 
> query for the data. Presumably
> 3761 since its 10 times faster than anything else out there. 
> 
> Sure that is probably how someone like myself would look at 
> the problem but there is empirical evidence that the model 
> works in large scaleable public network environments.
> 
> I don't see finding federations as much different.
> 
> > 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]
> > 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.,).
> > 
> > 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)?
> > 
> > tim
> > 
> > 
> > > Sent: Tuesday, September 19, 2006 2:21 PM
> > > To: [email-masked]; Stastny Richard; Andrew Newton
> > > Cc: [email-masked]
> > > ATIS has already put out an ANSI NNI standard.  Why reinvent that 
> > > wheel?
> > >
> > > I think it is important to realize that the world will 
> divide itself 
> > > up into federations based on their natural affinities, 
> and that they 
> > > won't all agree on the NNI profile.  So, it is better to 
> spend time 
> > > defining how to discover whether the party targeted by the E.164 
> > > number is in a federation shared with the calling domain, 
> or whether 
> > > a transit SP is needed, and which one, than to duplicate 
> the work of 
> > > other SDOs or forums.
> > >
> > > ENUM (of whatever flavor) helps to discover the 
> corresponding domain.
> > > A lookup based on domain helps to discover the federation.
> > > A lookup based on the federation helps to discover transit SPs 
> > > serving those federations.
> > >
> > > The above can be combined into a single lookup or done separately.
> > >
> > > Mike
> > >
> > >
> > > > Sent: Tuesday, September 19, 2006 2:58 PM
> > > > To: 'Stastny Richard'; 'Andrew Newton'
> > > > Cc: [email-masked]
> > > > Which are only 99.998 percent of the transactions right now.
> > > >
> > > >
> > > >
> > > > Yes SPEERMINT should define sometggregate data directly from other trusted 
> private registries into a locally cached database or have 
> their registry operator aggregate data from multiple sources for them.
> 
> How the data is "published" is presumably some form of out of 
> band provisioning interface and how the registry data is 
> acquired is also out of band..for now.
> 
> That data is then made available in a "useful format" such as 
> DNS NAPTR records per 3761 and the SS or whatever network 
> elements then.  
> 
> Frankly for US Carriers none of this should come as a 
> surprise..the routing tables for the North American PSTN are 
> a union of the Telcordia Local Exchange Routing Guide and the 
> Number Portability Database Administration ..currently 
> NeuStar. Those trusted data sources are merged into a Service 
> Control Point which a Class 5 switch queries for authorative 
> routing data.
> 
> IMHO the solution is multiple data sources merged into a 
> single view for routing. Everything else is how does the SS 
> query for the data. Presumably
> 3761 since its 10 times faster than anything else out there. 
> 
> Sure that is probably how someone like myself would look at 
> the problem but there is empirical evidence that the model 
> works in large scaleable public network environments.
> 
> I don't see finding federations as much different.
> 
> > 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]
> > 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.,).
> > 
> > 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)?
> > 
> > tim
> > 
> > 
> > > Sent: Tuesday, September 19, 2006 2:21 PM
> > > To: [email-masked]; Stastny Richard; Andrew Newton
> > > Cc: [email-masked]
> > > ATIS has already put out an ANSI NNI standard.  Why reinvent that 
> > > wheel?
> > >
> > > I think it is important to realize that the world will 
> divide itself 
> > > up into federations based on their natural affinities, 
> and that they 
> > > won't all agree on the NNI profile.  So, it is better to 
> spend time 
> > > defining how to discover whether the party targeted by the E.164 
> > > number is in a federation shared with the calling domain, 
> or whether 
> > > a transit SP is needed, and which one, than to duplicate 
> the work of 
> > > other SDOs or forums.
> > >
> > > ENUM (of whatever flavor) helps to discover the 
> corresponding domain.
> > > A lookup based on domain helps to discover the federation.
> > > A lookup based on the federation helps to discover transit SPs 
> > > serving those federations.
> > >
> > > The above can be combined into a single lookup or done separately.
> > >
> > > Mike
> > >
> > >
> > > > Sent: Tuesday, September 19, 2006 2:58 PM
> > > > To: 'Stastny Richard'; 'Andrew Newton'
> > > > Cc: [email-masked]
> > > > Which are only 99.998 percent of the transactions right now.
> > > >
> > > >
> > > >
> > > > Yes SPEERMINT should define something more than an NNI
> > > which is why I
> > > > suggest this be done in a series of profiles. Deal with 
> the SIMPLE 
> > > > problems first then proceed in measured steps.  This is 
> the IETF.
> > > >
> > > >
> > > >
> > > > Ending world (or SP)  hunger is not an immediate, 
> though laudable 
> > > > goal.
> > > >
> > > >
> > > >
> > > >   _____
> > > >
> > > > From: Stastny Richard [mailto:[email-masked]]
> > > > Sent: Tuesday, September 19, 2006 2:26 PM
> > > > To: [email-masked]; Andrew Newton
> > > > Cc: [email-masked]
> > > > 1. SNIP assumes that you are starting with an e:164 number
> > > >
> > > > 2. Speermint should do more than just defining an NNI
> > > >
> > > >
> > > >
> > > > Richard
> > > >
> > > >
> > > >
> > > >   _____
> > > >
> > > > Von: Richard Shockey [mailto:[email-masked]]
> > > > Gesendet: Di 19.09.2006 20:16
> > > > An: 'Andrew Newton'; Stastny Richard
> > > > Cc: 'Brian Rosen'; 'Klaus Darilion'; [email-masked]
> > > > Betreff: RE: [Speermint] Dear Collegues .. a modest proposal.
> > > >
> > > > Right ... well you maybe could use infrastructure enum to
> > > discover the
> > > > federation ... then a private tree to find the routing data
> > > but I have
> > > > serious doubts about that which is why I tend assume that
> > > some form of
> > > > first iteration SNIP probably deals with federation
> > > discovery out of
> > > > band.  I could be proven wrong however.  Again the idea 
> of SNIP is 
> > > > SIMPLE.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >   _____
> > > >
> > > > From: Andrew Newton [mailto:[email-masked]]
> > > > Sent: Tuesday, September 19, 2006 1:57 PM
> > > > To: Stastny Richard
> > > > Cc: Brian Rosen; Klaus Darilion; [email-masked]; 
> > > > [email-masked]
> > > > On Sep 19, 2006, at 1:52 PM, Stastny Richard wrote:
> > > >
> > > >
> > > >
> > > > Use draft-stastny-enum-ern-00
> > > >
> > > >
> > > >
> > > > This assumes public ENUM. I think the point is that most
> > > federations
> > > > use private ENUM.
> > > >
> > > >
> > > >
> > > > -andy
> > > >
> > > >
> > > >
> > > >
> > >

hing more than an NNI
> > > which is why I
> > > > suggest this be done in a series of profiles. Deal with 
> the SIMPLE 
> > > > problems first then proceed in measured steps.  This is 
> the IETF.
> > > >
> > > >
> > > >
> > > > Ending world (or SP)  hunger is not an immediate, 
> though laudable 
> > > > goal.
> > > >
> > > >
> > > >
> > > >   _____
> > > >
> > > > From: Stastny Richard [mailto:[email-masked]]
> > > > Sent: Tuesday, September 19, 2006 2:26 PM
> > > > To: [email-masked]; Andrew Newton
> > > > Cc: [email-masked]
> > > > 1. SNIP assumes that you are starting with an e:164 number
> > > >
> > > > 2. Speermint should do more than just defining an NNI
> > > >
> > > >
> > > >
> > > > Richard
> > > >
> > > >
> > > >
> > > >   _____
> > > >
> > > > Von: Richard Shockey [mailto:[email-masked]]
> > > > Gesendet: Di 19.09.2006 20:16
> > > > An: 'Andrew Newton'; Stastny Richard
> > > > Cc: 'Brian Rosen'; 'Klaus Darilion'; [email-masked]
> > > > Betreff: RE: [Speermint] Dear Collegues .. a modest proposal.
> > > >
> > > > Right ... well you maybe could use infrastructure enum to
> > > discover the
> > > > federation ... then a private tree to find the routing data
> > > but I have
> > > > serious doubts about that which is why I tend assume that
> > > some form of
> > > > first iteration SNIP probably deals with federation
> > > discovery out of
> > > > band.  I could be proven wrong however.  Again the idea 
> of SNIP is 
> > > > SIMPLE.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >   _____
> > > >
> > > > From: Andrew Newton [mailto:[email-masked]]
> > > > Sent: Tuesday, September 19, 2006 1:57 PM
> > > > To: Stastny Richard
> > > > Cc: Brian Rosen; Klaus Darilion; [email-masked]; 
> > > > [email-masked]
> > > > On Sep 19, 2006, at 1:52 PM, Stastny Richard wrote:
> > > >
> > > >
> > > >
> > > > Use draft-stastny-enum-ern-00
> > > >
> > > >
> > > >
> > > > This assumes public ENUM. I think the point is that most
> > > federations
> > > > use private ENUM.
> > > >
> > > >
> > > >
> > > > -andy
> > > >
> > > >
> > > >
> > > >
> > >

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 21 Sep 2006 19:13:08 -0400

Or, the transit provider may be the creator of the federation and
provide the much needed certificate authority for PKI to scale.

Mike

> Sent: Wednesday, September 20, 2006 3:58 PM
> To: Dwight, Timothy M (Tim)
> Cc: [email-masked]
> >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.
> 
> Transit providers may be normal members of the federation 
> being also members of other federations. 
>  
> Of course a federation may also choose to select one specific 
> VSP as transit provider
>  
> Richard
> 
> 
>

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 21 Sep 2006 19:42:15 -0400

Yes, perhaps too simplistic.  But, I would rather try to drive toward
simplicity, than design in complexity, which is what often seems to
happen.  

Mike

> From: Michael Haberler [mailto:[email-masked]] 
> Sent: Thursday, September 21, 2006 7:07 PM
> To: Michael Hammer (mhammer)
> Cc: [email-masked]; Stastny Richard; Andrew Newton; 
> [email-masked]
> Michael,
> inline -
> > You sign a contract with a federation (perhaps one run by a 
> carrier), 
> > get a certificate, provision your proxies, and go.
> >   
> That's too simple. You can't do that if you try to make 
> peering into a service a.k.a. revenue stream, even though 
> it's just a decision like in BGP. So much VSP autonomy breaks 
> some business assumptions.
> 
> But that of course depends on where you come from.
> > Why do you need to have bi-lateral contracts with all N-thousand 
> > members of the federation?
> >
> > That seems very manual and very complex in the number of 
> lawyers you 
> > would need. :)
> >   
> Well, if the assumption is that all the conceptual model of 
> SPEERMINT needs to support is the status quo, then this legal 
> haystack is already in place and leftover peering policy may 
> go into an ENUM view. Plus, perpetuating the contract model 
> creates deja vous with operations old hands since it's 
> business as usual.
> 
> Nevermind it's a colossal opex driver, and a lousy design 
> desicion in the first place: cramming peering policy into the 
> number layer is a surefire way to perpetuate the need of 
> E.164 addressing long after the world has moved on.
> 
> Important problem, wrong primary key for the solution - 
> bingo: instant legacy creation.
> 
> But I might be wrong - the other world view where things work 
> out under these assumptions is: the single "interesting" e164 
> resolution namespace and the single interesting federation 
> happen to be *one* same thing. As this fellow on VON said the 
> other week - "there can be only one".
> 
> Strikes me as "one way in, no way out" - if I were a VSP (carrier or
> enterprise) that wouldnt be exactly my first choice - lots of 
> eggs in a single nest. Again - depends where you come from.
> 
> -Michael
> > Mike
> >
> >
> >   
> >> Sent: Wednesday, September 20, 2006 6:26 AM
> >> To: Michael Hammer (mhammer); 'Stastny Richard'; 'Andrew Newton'
> >> Cc: [email-masked]
> >>> Sent: Tuesday, September 19, 2006 3:21 PM
> >>> ATIS has already put out an ANSI NNI standard.  Why
> >>>       
> >> reinvent that wheel?
> >>
> >> So why does SPEERMINT exist? See charter.
> >>
> >>     
> >>> up into federations based on their natural affinities, and
> >>>       
> >> that they
> >>     
> >> or whether a
> >>> transit SP is needed, and which one, than to duplicate 
> the work of 
> >>> other SDOs or forums.
> >>>
> >>> A lookup based on the federation helps to discover transit
> >>>       
> >> SPs serving
> >>     
> >>> those federations.
> >>>       
> >> IMHO this is a very complex problem. I simply wonder if this is 
> >> better done out of band as part of classical bi-lateral 
> relationships 
> >> between providers but accessed locally as part of some cached data 
> >> base.
> >>
> >> I simply refuse to believe that any advertisement of 
> membership in a 
> >> federation or ability to route against a specific number range (s) 
> >> will not be backed up by written contracts.
> >>
> >> If I'm a SP I would never accept traffic unless A. I had 
> positive and 
> >> authenticated knowledge of where the traffic is coming 
> from and B. a 
> >> signed commercial agreement on how that traffic is to be handled.
> >>
> >> There is no transit or peering agreement on the internet 
> now that is 
> >> not backed up by commercial agreements. I see no reason 
> that is going 
> >> to change.
> >>
> >> But I could be wrong.
> >>
> >>     
> >> which is why
> >>>> I suggest this be done in a series of profiles. Deal with
> >>>>         
> >> the SIMPLE
> >>     
> >>>> problems first then proceed in measured steps.  This is the IETF.
> >>>>
> >>>>
> >>>>
> >>>> Ending world (or SP)  hunger is not an immediate, though 
> laudable 
> >>>> goal.
> >>>>
> >>>>
> >>>>
> >>>>   _____
> >>>>
> >> discover
> >>>> the federation ... then a private tree to find the
> >>>>         
> >> routing data but
> >>     
> >>>> I have serious doubts about that which is why I tend assume that 
> >>>> some form of first iteration SNIP probably deals with federation 
> >>>> discovery out of band.  I could be proven wrong however.
> >>>>         
> >> Again the
> >>     
> >>>> idea of SNIP is SIMPLE.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>   _____
> >>>>

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Fri, 22 Sep 2006 10:40:18 -0400

Tim,

The addition of a federation identity to the DNS lookups helps provide
the linkage and add scalability above the level of domains.  Lookups of
both the target VSP and the transit VSP can point to a common
federation.  Also, lookup of a federation could point to transit VSPs
that support that federation.  The addition of these simple mappings can
help provide a series of mappings that enable L5 routing from A to B.

Mike

> Sent: Friday, September 22, 2006 1:44 AM
> To: Michael Hammer (mhammer); Stastny Richard
> Cc: [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]
> > Tim,
> > By serving, I meant willingness to originate or terminate traffic 
> > to/from that federation to other federations.
> > 
> > Mike
> >  
> > 
> > > Sent: Wednesday, September 20, 2006 12:59 PM
> > > To: Stastny Richard
> > > Cc: [email-masked]
> > > Thanks, Richard.  Other comments inserted below.
> > > 
> > > tim
> > > 
> > > > 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.
> > > 
> > > 
> > > 
> > > > 
> 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
> > > 
> > > > >   Are we
> > > > could be, but not necessarily
> > > >  
> > > > Richard
> > > > 
> > > > >tim
> > > > 
> > > > 
> > > > 
> > > > 
> > >

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Fri, 22 Sep 2006 10:52:28 -0400

Inline. 

> To: Michael Hammer (mhammer); [email-masked]; Stastny 
> Richard; Andrew Newton
> Cc: [email-masked]
> federation"?  Are
> we
> > >    assuming some sort of federation-level interconnection (i.e.,
> that
> > 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.

In the DNS entry, the target VSP can list the federations and indicate
priority.

> > 
> > 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. 

Actually, this type of federation is no different from any other
federation in terms of how it operates.  I was only suggesting that if
all the transit carriers wanted to get together and create a federation
where all members are transit VSPs, they could.  When they indicate
membership in such a federation and then also list federations they have
access to, it should be obvious how transit VSP-O can work backwards
from target VSP -> target federation -> VSP-T with whom, using T
federation rule, to connect to deliver the call. 

> > 
> > 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.

The mechanisms allow the process to be simple; the market determines who
is most efficient at delivering the calls resulting in the optimal N.

Mike

> > [snip]