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

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 19 Sep 2006 12:31:50 -0400

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.

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: "Richard Shockey" <[email-masked]>
Date: Tue, 19 Sep 2006 13:10:42 -0400

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

OK ... that's a fair point certainly negotiable.but what about the general
principal of a SPEERMING SNIP profile as a direction forward?