1. i3forum IPX Self Certification tool kit Initial thoughts (October 2016) + notes from Nov 10 WG conf call + notes from Nov 22 WG conf call + notes from Dec 14 WG conf call + notes from Jan 10 WG conf call Philippe Millet Dec

2. IPX self-certification tool kit – context and objectives
one of the learnings from the i3forum survey conducted in April 2016 is that there still seems to be confusion in the market regarding the definition of IPX, and that seems to slow down adoption
also, even if the i3forum’s recommendations seem to be well known and used, it appears that the collective learning curve is slow - it has not got significantly easier or faster to set up IPX interconnections.
in addition, the GSMA has analyzed IPX uptake amongst MNOs and some of their conclusions are similar to ours (even if some other aspects are playing into it, including complexity / openness of the specifications, business case concerns…)
Objectives :
The objective is to foster adoption of IPX by Carriers and MNOs by helping to alleviate two obstacles :
Confusion about IPX – that slows down the decision making
Complexity and lack of guidance - that slows down implementation
Full certification of IPXs (by a third party, with tests etc..) does not seem practical, nor maybe desirable
So the idea is to develop (jointly with GSMA as much as possible), an industry approved “IPX self-certification tool kit” that IPX providers - and their customers - can use in order to :
clarify what their IPX offer (or requirement) is - and isn’t - against a commonly agreed IPX definition
describe key technical, operational and services features against commonly agreed recommendations & best practices. One approach could be to separate “core” characteristics from a (limited ?) set of optional features.
accelerate and simplify implementation by leveraging practical tools derived from industry best practices (e.g. interconnection form, test plans, choice of options, set parameters, project templates……) - something like “Interco in a box”
one additional item could be some work on a business case template – this was raised by the GSMA and they might be working on it.
This needs to be a practical, readable document, aiming at helping all parties agree the same understanding of IPX against a well-defined and industry endorsed referential.
This is not a specification of IPX, nor a binary “must comply” certification approach. It is not meant to rank or rate IPXs.

3. IPX self-certification tool kit – how to go about it
There might be three components to the tool kit
a (somewhat high level) definition of IPX – incl what’s core, what’s optional, what’s not IPX. Ideally this would need to be agreed by both organizations
a list of features – technical, operational, service related…
a set of practical tools – guidelines, recommendations, templates…
leverage existing i3forum (and GSMA ) documents. There is a lot of material available, we’re not starting from scratch
leverage “real world” experience and best practices from the most advances carriers – the initial documents were put together when IPX did not really exist, but now there is a wealth of experience to draw from
be ready to revisit – possibly extensively – some existing documents, especially detailed specifications. This will take time (so maybe not completed for version 1) but the thinking including on the GSMA side) is that one of the obstacles is that IXP is too complex, too open, that we need less options. Part of this will need do be done with (and by) other work groups
agree a roadmap – version 1 won’t be it all but we probably need to have something available by ITW 2017 – even if not final or perfect
Also we need to understand how much of a joint GSMA-i3forum tool this needs to be. Reaching 100% agreement might take a long time, when overall consistency and strong agreement on some parts could be easier to reach
Last but not least, we need work on how we will deliver this to the “market”, promote it and hopefully get feedback to improve it. From experience, posting it on our website won’t be enough if we want to make a difference

4. Notes from November 10 WG conf call (please feel free to add / adjust if I missed anything)
Documents gathered by BTS, Orange, Tata : GSMA’s IR34, existing i3forum documents, documents fond online
To be shared with the rest of the group
Documents from i3forum’s “Operations” WG are focused on VoIP, significant work needed to create similar documents for IPX
Suggestion that participants share their own IPX product definition
Also explore how we can leverage the work of the IMS WG (IMS, VoLTE)
Suggestion that we split the “Certification” tool kit in several sections
General definition of IPX (including what IPX isn’t)
Transmission (the “pipe”) – focus on what is specific to IPX
several sections on the various services (Voice, Signaling, data….) – IPX is NOT just Voice
This could also help us have a step by step approach to the Certification document, starting with Transmission and maybe Voice ?
Also, it would be interesting to discuss the value of IPX, what makes the business case more compelling, various use cases and glide paths to “full IPX”, how IPX ties into IMS interconnections
How detailed do we want to be ? The objective could be to fill the gap between very high level, conceptual definitions of IPX and detailed specifications, with a document that is “readable” but provides sufficient level of details to be tied to actual implementations
Next step : it is suggested that WG participants start from the i3forum definition of IPW (April 2013) and build on it, commenting what’s missing, what level of details should be added, topics that should be explored, what is maybe obsolete etc… so as to help everyone organize their thoughts
Tata offered to draft a “one pager” to serve as tha “launching pad” for the WG

5. Notes from November 22 WG conf call (6 participants: Orange, Tata, iBasis, BTS)
New inputs (see Antonino’s prior to the call)
Greg and Ken shared a word document to serve as a “launching pad” for our work
Tanit shared two documents, a presentation from Telia Carrier on “What IPX is”, and a .ppt with a list of IPX definitions from various sources
The group reviewed and discussed all three documents - all agree to keep using the “launching pad” document and build on it
Discussion on whether MPLS is the only way to build an IPX interconnection
Discussion on whether we should highlight a number of key points/features (technical etc..) on top of referencing detailed technical specifications
Evolve the document to include sections for each component, starting with “the pipe” (the interconnection it self) and adding a section for each service (e.g. voice, signaling, data…)- as discussed last time
Add a general introduction, that would discuss the concept of IPX, and include several definitions available in the market (and from the survey conducted earlier this year) and highlight what they have in common. Also include some of the points made in the Telai presentation (after they agree)
Add examples / use cases to clarify things
Actions for next call :
Antonino will contact Isabelle Paradis to get raw results of survey re: the IPX definition provided by respondents
Tanit will keep gathering IPX definitions and start working on what they have in common
Greg will update the “launching pad” document and start focusing on the interconnection aspect
Chris to provide comments on the use of MPLS and alternative options
All to provide further comments on the document shared by Greg as well as on the 2013 definition of IPX published by the i3forum. All to keep reviewing IPX definitions and product specs

6. Notes from December 14 WG conf call (6 participants: Orange, Tata, AT&T, Telia)
New inputs :
Greg shared an updated version of the “launching pad” document. Unfortunately we didn’t have time to review it during the call, please share any comment or suggestion you might have
Tanit shared an analysis of the IPX definitions used by 11 carriers (anonymized), looking for commonalities (key word analysis).
This was reviewed and discussed during the call, and proved very interesting both from a “real world IPX definition” point of view and also as a possible model for a “self-certification” tool.
Among other things, it would be interesting to perform the same analysis on the IPX definitions submitted by the carriers who responded to the i3forum survey earlier this year (Antonino, could you share the raw data you got from Isabelle ?)
Philippe shared feedback from the discussion at the Board meeting early December. The Board approved our WG’s approach and confirmed that the i3forum’s definition of IPX (April 2013) remains relevant and should be used as the foundation for our work.
Several key points / comments were made during the very interesting discussion we had. Let me know if I missed or misunderstood anything :
Need to clarify the distinction between the notion of “the IPX model”, and the various services that can ride on it (or not)
All agree that two of the key features of an IPX are : private network (no public internet) and multiservice capability (even if early IPXs focused on one or two services only).
Discussion on whether the “2 hops max” requirement is a key feature for an IPX, current i3forum definition says it isn’t - in line with real world market feedback. However SLAs become more complicated to implement when there are more than2 hops (see i3forum’s previous work on Quality)
IPX services can be “service aware” (e.g. voice) or “service unaware” (e.g. transport), that does not affect the definition of an IPX
There is an “evolutionary story” to be told about IPX, with two tracks (IPX by GRX/data players, IPX by Voice players). One track (data) might be stronger than the other. “Killer services” are different on the two sides (GRX, voice). The two tracks are (will be?) converging to create truly multi-service offers.
Suggestion that we look into what MEF has done to define an framework architecture for Layer 2 (UNI, NNI) and how we could take a similar approach for IPX (NB : see also i3form’s previous work on a reference architecture for IP intercos, recommended profiles etc…)
Actions for next call on Jan 10 at 4pm CET :
Philippe to look into MEF’s work
Mike to take a stab at drafting the “evolutionary story”
Greg and Tanit to keep refining their documents – all to provide any comment they might have

7. Notes from January 10 WG conf call (5 participants: Orange, Tata, AT&T)
New inputs :
Tanit shared an updated version of the analysis of the IPX definitions used by 11 carriers (anonymized), looking for commonalities (key word analysis). We didn’t not have time to review it
The team reviewed Greg’s updated “launching pad” documents from December (that we didn’t have time to discuss during the previous call) – we focused on the new “architecture of the “pipe”” section (reminder : we are thinking of structuring the document with a first section about “the pipe” and then several sections for each of the various IPX services.)
Several key points / comments were made :
Should we focus on MPLS ? Agree that the key concept is that IPX is a private IP connection (i.e. not over public Internet). Several ways to implement this (VPN, IPLC…) but the most common way (by far) is MPLS (for several reasons that we will list). Consequently, in order to be practical, the document will mention the other methods, discuss the pros and cons, but focus on MPLS. The question was even asked if we should mandate MPLS ?
Definition of what the “pipe” is : it is the common denominator for all IPX interconnections, on which IPX services can be built. Is that the same as IPX Transport (service unaware) ?
“key features of the “pipe”” : It was suggested that we list separately
What needs to be exposed at the interface
“best practices” for “internal” set-up
We clarified that the “Self Certification Tool Kit” is not a spec. It should be a practical, “easy read” document, 10 to 20 pages that non specialists can use, that sits somewhere in between the “powerpoint one page definition” and the detailed specifications or recommendations (GSMA, i3forum…)
Actions for next call on Jan 25 at 4pm CET :
Mike to take a stab at drafting the “evolutionary story” (see discussion on Dec 14)
Greg asks all contributors for revisions / suggestions on the “launching pad” document
We will also review Tanit’s updated document