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

From: "Richard Shockey" <[email-masked]>
Date: Tue, 19 Sep 2006 09:38:00 -0400

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

---

From: Klaus Darilion <[email-masked]>
Date: Tue, 19 Sep 2006 19:10:34 +0200

Hi Richard!

> What we cant do ... right now.
...
> what that policy should look like.

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

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 19 Sep 2006 13:34:10 -0400

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

> -----Original Message-----
> From: Klaus Darilion [mailto:[email-masked]]
> Sent: Tuesday, September 19, 2006 1:11 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Speermint] Dear Collegues .. a modest proposal.
> 
> Hi Richard!
> 
> 
> 
> Richard Shockey wrote:
> >

---

From: "Stastny Richard" <[email-masked]>
Date: Tue, 19 Sep 2006 19:52:20 +0200

>This means you can't do federation discovery
 
You can
 
Use draft-stastny-enum-ern-00 to detect the enum federations
and draft-lendl-speermint-federations-03 for speermint federations
 
Richard

________________________________

Von: Brian Rosen [mailto:[email-masked]]
Gesendet: Di 19.09.2006 19:34
An: 'Klaus Darilion'; [email-masked]
Cc: [email-masked]
Betreff: RE: [Speermint] Dear Collegues .. a modest proposal.

Brian

---

From: Andrew Newton <[email-masked]>
Date: Tue, 19 Sep 2006 13:56:43 -0400

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: "Stastny Richard" <[email-masked]>
Date: Tue, 19 Sep 2006 20:08:17 +0200

>This assumes public ENUM.  I think the point is that most federations use private ENUM.
 
Yes, but ern points also to private ENUMs
 
Richard

---

From: Andrew Newton <[email-masked]>
Date: Tue, 19 Sep 2006 14:14:17 -0400

> Yes, but ern points also to private ENUMs

Because it is tied to infrastructure ENUM, it is rooted in a public  
tree... which have been oh so successful to date.

BTW, if multiple federations can route an E.164, then how performs  
the gating function of which federations are allowed to add their  
private pointers?

-andy

---

From: "Stastny Richard" <[email-masked]>
Date: Tue, 19 Sep 2006 20:14:28 +0200

Did you read the ern-draft?
 
Richard

Von: Andrew Newton [mailto:[email-masked]]
Gesendet: Di 19.09.2006 20:14
An: Stastny Richard
Cc: Brian Rosen; [email-masked]
Betreff: Re: [Speermint] Dear Collegues .. a modest proposal.

-andy

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 19 Sep 2006 14:16:04 -0400

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]
Subject: Re: [Speermint] Dear Collegues .. a modest proposal.

This assumes public ENUM. I think the point is that most federations use
private ENUM.

-andy

---

From: "Stastny Richard" <[email-masked]>
Date: Tue, 19 Sep 2006 20:25:45 +0200

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. 

 

-andy

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 19 Sep 2006 14:57:30 -0400

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]
Subject: Re: [Speermint] Dear Collegues .. a modest proposal.

Richard

  _____  

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. 

  _____  

 

-andy

---

From: Andrew Newton <[email-masked]>
Date: Tue, 19 Sep 2006 21:27:42 -0400

Richard,

Before this thread gets much more off course, it should be noted that  
what you have stated here sounds similar to what I heard Jon Peterson  
say when he was trying to clarify the charter/milestones (which arose  
from several questions about what exactly a requirements document for  
a BCP was).

I'll try to summarize it once again:

Jon noted that there were many types of peering relationships, and  
that they will differ in many ways, especially in "static" peering.   
The intent of our BCP milestone was that we create best current  
practices for the various technologies or components that could be  
used in peering, not a best current practice that states that they  
all must be used.  The point of using the words "minimum set" in the  
milestone was that he did believe that all peering relationships  
would have a couple of things in common (e.g. RFC 3261).  The two  
examples of ENUM and TLS were used.  So if a peering relationship is  
to use ENUM or TLS, then it would be wise to follow the SPEERMINT BCP  
on ENUM or TLS... but there would be no best current practice stating  
that all peering relationships should use either.

Does that sound similar?  If so, I'm in agreement.

-andy

---

From: "Uzelac, Adam" <[email-masked]>
Date: Tue, 19 Sep 2006 21:53:41 -0400

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.

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

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

> > B. Federation Discovery and Policy. How you find a federation what 
> > are
> the
> 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).
> > --------------------------------------------------------------------
> > ----
> ----
> > ----
> > 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
> > while using packet marking techniques. Current attempts to deliver 
> > QoS
> using
> > 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
> > caused by route changes due to link or router failure) pre-emption 
> > of
> some
> > 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
> > headers when their traffic is above a certain level, as an early 
> > warning
> of
> > incipient congestion ("pre-congestion"); this builds on concepts 
> > from
> RFC
> > 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).
> >
> > 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
> > 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
> >
> > 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>

---

From: Shawn Pouliotte <[email-masked]>
Date: Tue, 19 Sep 2006 22:50:24 -0700

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.

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

Brian

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 20 Sep 2006 06:10:58 -0400

> Sent: Tuesday, September 19, 2006 9:28 PM
> To: Richard Shockey; [email-masked]
> Subject: SIMPLY SNIPpy (was Re: [Speermint] Dear Collegues .. a modest
> proposal.)
> 
> Richard,
> 
> all must be used. 

Yes... I'm in complete agreement. Which is why I noted that for AA its
conceivable that SP could use big yellow wire, IP SEC or TLS but not that
they must be used...only supported.

 The point of using the words "minimum set" in the
> Does that sound similar?  If so, I'm in agreement.

Yes.. I certainly accept that discovery, for instance, may not necessarily
use 3761 but some form of cached data that was exchanged in an out of band
mechanism.

Any form of what I refer to as SNIP is clearly a BCP. 

> > are the
> > of this
> > that
> > of how
> > QoS using
> > of some
> > (PIN) and
> > case of a
> > warning of
> > from RFC
> > control and
> > work,
> > problem