February 2015 - Nsi-wg - lists.ogf.org

Authorization in NSI
by John MacAuley 10 Mar '15

10 Mar '15

Peoples, Before Christmas I pulled together an NSI security omnibus capturing content from Han's AAI document and discussions we had been having on the mechanisms needed to convey security information in the NSI protocol. In addition, I tried to capture the routing policy requirements we have been discussing so I could have a clear view of what issues we are trying to solve. This lead to me writing a proposal for two solutions for the enforcement of end-to-end routing policy that require no changes to the existing CS protocol. As we start preparing for the Washington meeting I have decided to break the document up into three (or four) slide packages for discussion/presentation. I have attached the first of these slide packages. This one deals with the fundamental principles of security in NSI, and the topic of end user Authorization. Included in the slide package is the definition of an "originatingId" as agreed to in Uppsala last September. It captures the identifier of the originating uRA and the identity of the requesting user/application. In addition, it shows how end user authorization information can be generically included in the NSI header for use by end uPA. Thank you, John

2 2

Pathfinding and Service (a new topology suggestion)
by Henrik Thostrup Jensen 02 Mar '15

02 Mar '15

Hi (part three on security and pathfinding). This one ended up being not so much about security, and more about pathfinding and services. And quite long. Sorry about that. We currently have a number of topology suggestions. None of them can adequately describe complex transit policies. I will try to address the issues of NML and GNS (The UvA suggestion is not a topology model), suggest a new model and present some further issues which we haven't considered yet. * Overview The main policy tool of NML is the switching service, which describes how ports in a node can be connected. This approach falls short when selective transit is provided, as this cannot be described as a switching service. It also means that it is not possible to enforce this policy locally by looking at the cross connect. The GNS suggestion announces reachability to other networks, done at NSA level. Hans pointed out that it should really be per network. However there are cases where networks are connected over multiple links with different policies, meaning that reachability would have to be provided per link. This approach is then getting awfully close to that of BGP. In BGP all reachability is explicit, as IP prefixes are announced (default route is the exception, but reachability is still explicit). Further, AS paths are announced, which makes it possible to build a network model. This enables faster recovery in case of link/router failures as it is possible to re-route traffic more efficiently. This is typically only done in backbone networks. Unlike BGP, NSI does not have a mechanism for aggregating its address space (ports). Since Uppsala, we can infer the network from the port name, however there is no way indicating which ports are closer to a certain demarcation link, which makes optimal pathing difficult. However, it is possible to split a network into multiple smaller networks for this, but a metric is still needed. No good technical metric exists to announce distances, and due to link pricing and policies, a distance metric must be administrative (works well in BGP). * Network & Services Given our decision to link STPs and network identifiers it becomes possible to do path finding to a network, instead to a specific port. This drastically reduces the amount of information a path finder must be aware of, and removes the problem of connecting to newly created STPs. Path finding per network is somewhat difficult in NML as the problem of adaptation between technologies in order to get the right service requires intricate knowledge of the capabilities of the networks. IP solves this problem by being a single universal service that can live on top of different technologies. Since we want to be able to provide multiple service types through NSI, this will not work for us. We also been struggling quite a bit of tying together technology, adaptations and services in NML as the combination becomes complicated quite quickly. Recently I've talked to several persons about the ANA infrastructure. The ANA infrastructure is interesting as the hardware comes from multiple vendors, and the infrastructure must provide different services (best effort circuits, circuits with guarantied bandwidth, and the same with protected circuits). Focusing on technological capabilities becomes quite messy in this scenario. Instead the important thing is to focus on what services can be provided, and let the NSI Agents handle the service to technology mapping. This is quite different from our previous approach. In short: I think we need to move to a model that is service centric instead of focusing on the technology of the equipment. * Topology Model I suggest a model that focuses on describing capability instead of the basic resources. It is based around two principles: - Network Reachability - Service Capability The first allows us to express complex transit policies in simple and well proved way (BGP). The second allows us to abstract away technology specific models and focus on what can services can actually be provided. This model puts policy and services before technological capabilities. By describing reachability, path finding becomes simple and predictable. This is major advantage over the graph search approach in NML which can produce extremely unfortunate effects such as cross-atlantic loops. Defining reachability will require manual work, however this will always be the case when describing policies. Here is how the topology description could look like in XML: <Network id="urn:ogf:network:aruba" version="123"> <Name>Aruba</Name> <Link id="urn:ogf:network:aruba:bonaire-otn" demarcation="urn:ogf:network:bonaire:aruba-otn"> <Name>Bonaire OTN Link</Name> <Service type="EVTS"> <ReachableNetwork id="urn:ogf:network:bonaire" distance="1" /> <ReachableNetwork id="urn:ogf:network:curacao" distance="2" /> </Service> <Service type="OTN"> <ReachableNetwork id="urn:ogf:network:bonaire" distance="1" /> </Service> </Link> <Link id="urn:ogf:network:aruba:dominica-eth" demarcation="urn:ogf:network:dominica:aruba-eth"> <Name>Dominica Ethernet Link</Name> <ServiceTransit type="EVTS" /> </Link> <Service type="SwitchingService" /> </Network> The topology description is really more of a transit table for services than an actual topology description (however we have never been describing topology, only networks and demarcations). Reachability is unidirectional and cannot be turned around, however the service provided might bidirectional. The description covers what the link can be used for from outside the network. The above example describes a network (Aruba), with two links. First link is an OTN link towards the Bonaire network. This link provides two services: EVTS and OTN. The EVTS service can reach the bonaire and curacao network, where the OTN service can only reach bonaire. How the EVTS service is carried on the OTN link is up to the aruba and bonaire network. The details are encapsulated. The second link in the network is an ethernet link towards the dominica network. This link provides what is called service transit, for the EVTS service. This means that the dominica can use the link to connect to any EVTS endpoint in the NSI system. This is similar to the concept of a default route in BGP. Finally a switching service is listed in the network. This denotes the capability to create a service in the network. There are several choices and tradeoffs in the design: - Only describe demarcation links. This means significantly less data to distribute and that the data will be fairly stable. This also removes the need for complex distribution mechanisms. - For each link, the supported services and reachable network for each service is listed along with a cost. This makes path finding straightforward: Select the link that provides reachability to the desired network that has the lowest value. Cost is an administrative value. Lower is better (think hops). The service first structure was chosen as I suspect it will be the smallest, but it could as well be network first and services listed under that. If a network cannot bridge a service type from one link to another, reachability for that network is not announced on link. This encapsulates complicated technology restrictions in a simple way, that would otherwise have to be built-in to pathfinders. - A link can provide service transit. This means that all networks supporting the service type should be reachable through that link. This would typically be used by a backbone network towards its customers. A customer may have other links that it could favor for some networks. Similar to how most networks have a transit provider, but will have private peering/links to other networks. - Can describe network services Some networks may provide services that are hosted in the network. This could be a switching service which could be used to connect p2p links in order to build a multi-domain switched network (I'll refrain from debating if this is a good idea). A list of potential network services: - Switching service. Will on creation return a number of STPs that can be used to connection P2P links - Aggregation. Aggregate the data from two or more unidirectional circuits into one. - Ping service Provides an STP with a pingable address. The network may of course also supply these like today with pre-configured STP. - Perfsonar Would spawn a perfsonar instance and return an STP endpoint. Label swapping capability is intentionally left out. We should stop engineering for old technology, and underspecified STPs goes a long way towards solving the issue if it should occur. By describing services and the capabilities of the network in this way, it becomes easier to introduce new services and possible to describe policies that would otherwise be complicated or impossible to express with previous suggestions. * Pathfinding As the networks explicitly describe reachability, an NSI Agent only needs to fetch the topology (service table) document from its peers to know which networks are reachable. This means that a document-distributing system is not necessary, as the connections between networks is largely static. The reachability document would only have to be updated at low intervals. For leaf networks, an NSA would simply be setup with another NSA as its transit provider. This NSA would then leave all pathfinding to be done by the backbone network. This situation is similar to how many organizations and smaller NRENs have a single transit provider, which does all their connectivity. The scheme assumes a chain-like path setup, which is intentional. Setting up a circuit in chain mode allows each NSA to verify that the transit policies of the network is enforced as it can see the destination network, and check it against announced reachability. It is not possible to perform such a check for UPAs when a circuit is setup in tree mode, as only the crossconnect is know. However chain mode will probably have to broken when crossing exchanges, as the NSI agents for such will typically be UPAs and not care about transit policies and link AUPs. Please refer to my previous email on secure crossing of exchanges for details on this. This means that we will end up with a hybrid pathfinding that does a tree with one branch being one layer deep each time an exchange is crossed. As chain pushes the decision for how to connect downstream, it does not allow the same control over the circuit (unless using EROs). However delegating this decision is likely to lead to fewer circuit setup failures. Consider the following setup: A = B = C Three networks: A,B and C. A and B are connected via two links, and similar for B and C (the = sign is two links). If A wants to create a circuit to C, it will setup a link to B and ask B to setup a cross connect into C. If one of the circuits between B and C cannot support the capacity, B can automatically choose the link with enough capacity to C. Only B and C has the knowledge about the state of their link, and are hence better suited towards taking the decision of which one to use. With explicit reachability and distances the process for setting up circuits becomes simpler and more predictable. The distance vector in particular makes sure that an optimal path is taken. This in contrast to NML that has no mechanism to prefer certain paths over others. * Handling Failure in Pathfinding Handling failure circuit(service) setup failures and attempting alternate paths (re-pathing) with only reachability information can be a bit tricky. This section covers how this can be solved. Currently we have the notion that aggregators should not try and fix failures, only return them to the UPA. If we relax this latter notion, it opens up the possibility for aggregators along the path to try alternate paths. However such attempts should be restricted to certain behavior, e.g., a backbone network can try alternative links towards a customer. Re-pathing should not use transit/peers towards customers or use transit to go to peers. If the notion of aggregators not being able to re-pathing holds, it is possible for a UPA to perform re-pathing, by constructing an ERO that doesn't take the link without enough capacity. Constructing such an ERO is likely to require more information than what is available from the topology of the peers and transit provider for the UPA. To construct the ERO it would have to fetch the topology of the backbone networks to build up a model of the network to find an alternative path. The reason only backbone networks is relevant is that end organization are typically multi-homed into the same provider, which makes smaller network largely irrelevant for re-pathing. Since the number of backbone network is relatively small and the information in their topology description is largely static, fetching them directly is simple and convenient. Performing re-pathing at the UPA is however suboptimal. Leaf networks will typically be very limited in their connectivity, where the service provider (backbone network) will have a much degree of connectivity. Hence it makes sense for the service provider to perform re-pathing. This is similar to how BGP re-routing is not done by smaller tier-2 and tier-3 networks. Re-pathing at smaller networks does not make sense as their connectivity is typically rather limited. However customers and providers can agree where and if re-pathing should be done (similar to how some IP customers get a full routing table, and others do not) Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet

2 2

IETF forms Network Function Virtualization Research Group
by Guy Roberts 27 Feb '15

27 Feb '15

Hello All, I thought you might like to know that the IETF are setting up an NFV research group, details below... Topic: The NFVRG will focus on research problems associated with NFV-related topics and on bringing a research community together that can jointly address them, concentrating on problems that relate not just to networking but also to computing and storage aspects in such environments. It is hoped that the outcome of the research will benefit research efforts in other groups within the IRTF (and especially the SDNRG) and standardization activities of IETF WGs (like the ones going in SFC). Specific results can also spawn activities via IRTF & IETF BoF meetings and/or provide useful input to other related efforts in the ETSI NFV ISG or other standards bodies. Link: https://datatracker.ietf.org/doc/charter-irtf-nfvrg/ _____________________________________________________________________ Guy Roberts PhD Senior Transport Network Architect GEANT Limited Email: guy.roberts(a)dante.net<mailto:guy.roberts@dante.net> Tel: +44 (0)1223 371316 Mob: +44 (0)7881 336417 GEANT Limited is part of the GÉANT Association Networking. Services. People Learn more at: www.geant.org<http://www.geant.org/> and www.dante.net<http://www.dante.net/> GEANT Limited registered in England & Wales. Registration Number 2806796. Registered Office - City House, 126-130 Hills Road, Cambridge CB2 1PQ _____________________________________________________________________

1 0

Minutes for today's NSI call (Feb 25 2015)
by Chin Guok 26 Feb '15

26 Feb '15

Hi all, Here are the minutes for today's meeting. Please correct as necessary. Thanks! - Chin -- Chin Guok NOC: (510) 486-7600 Network Engineer (800) 333-7638 ESnet Network Engineering Group (AS293) Lawrence Berkeley National Laboratory

1 0

Slides for phone call presentation on February 25th
by Henrik Thostrup Jensen 24 Feb '15

24 Feb '15

Hi Here are the slides for tomorrows presentation. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet

1 0

Fwd: Invitation to the joint SDOs/Fora Workshop (4th June at TMF Week in Nice): on Industry Harmonization for Unified Standards on AMC (Autonomics), SDN, NFV, 5G, ..
by Sill, Alan 21 Feb '15

21 Feb '15

Dear Richard and folks in the NSI group, I received the invitation below, which was also addressed to Richard, so he should also have gotten it. I am unable to attend the event mentioned at that time, but thought you might consider interacting with that group, and with the author of the paper mentioned. The link to that paper was not provided in the message, but appears to be http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6979980 Any representation of OGF work in this or other settings in which issues relevant to our work would be appreciated. Also advice to the community in terms of informational, community practice or other relevant OGF documents that would help make sense of the landscape here, especially for cloud, grid and other forms of distributed computing, would be welcome. Please let me know if you would like to attend this event on behalf of OGF> We have an existing MoU with TM Forum on work on service agreements, and one to extend this work with them or with other relevant organizations for other cooperative or joint work is possible. Please also feel free to suggest BoF sessions on this or other relevant topics for this or other possible new work at OGF 43 March 25-27 near Washington DC, or at OGF 44 to take place May 21-22 during the week of the EGI Spring Conference in Lisbon, or at other upcoming events. Thanks and best regards, Alan Sill VP of Standards, OGF Begin forwarded message: Date: February 20, 2015 at 8:59:56 AM CST From: Ranganai Chaparadza <ran4chap(a)yahoo.com<mailto:ran4chap@yahoo.com>> Reply-To: Ranganai Chaparadza <ran4chap(a)yahoo.com<mailto:ran4chap@yahoo.com>> To: "georgedobrowski(a)mail01.huawei.com<mailto:georgedobrowski@mail01.huawei.com>" <georgedobrowski(a)mail01.huawei.com<mailto:georgedobrowski@mail01.huawei.com>>, BEN MERIEM Tayeb IMT/OLN <tayeb.benmeriem(a)orange.com<mailto:tayeb.benmeriem@orange.com>>, Kenneth Dilbeck <kdilbeck(a)tmforum.org<mailto:kdilbeck@tmforum.org>>, "STEVEN A. WRIGHT" <sw3588(a)att.com<mailto:sw3588@att.com>>, John Strassner <john.sc.strassner(a)huawei.com<mailto:john.sc.strassner@huawei.com>>, John Strassner <strazpdj(a)gmail.com<mailto:strazpdj@gmail.com>>, "Klaus Martiny" <klaus.martiny(a)telekom.de<mailto:klaus.martiny@telekom.de>>, STEFAN ENGEL-FLECHSIG <stefan.engel-flechsig(a)ngmn.org<mailto:stefan.engel-flechsig@ngmn.org>>, Klaus Moschner <klaus.moschner(a)ngmn.org<mailto:klaus.moschner@ngmn.org>>, "manish_patil(a)dell.com<mailto:manish_patil@dell.com>" <manish_patil(a)dell.com<mailto:manish_patil@dell.com>>, Mehmet Ulema <mehmet.ulema(a)manhattan.edu<mailto:mehmet.ulema@manhattan.edu>>, Takashi Egawa <t-egawa(a)ct.jp.nec.com<mailto:t-egawa@ct.jp.nec.com>>, FRANCISCO JAVIER RAMON SALGUERO <fjrs(a)tid.es<mailto:fjrs@tid.es>>, Latif Ladid <latif(a)ladid.lu<mailto:latif@ladid.lu>>, Ciprian Popoviciu <chip(a)nephos6.com<mailto:chip@nephos6.com>>, Corbi Cecilia Maria <ceciliamaria.corbi(a)telecomitalia.it<mailto:ceciliamaria.corbi@telecomitalia.it>>, Christiantoche Toche <christian.toche(a)huawei.com<mailto:christian.toche@huawei.com>>, Niranth Amogh <namogh(a)huawei.com<mailto:namogh@huawei.com>>, "Chenshan (Sunny)" <chenshan(a)huawei.com<mailto:chenshan@huawei.com>>, 'Zoltán Lajos Kis' <zoltan.lajos.kis(a)ericsson.com<mailto:zoltan.lajos.kis@ericsson.com>>, Pinnola Andrea <andrea.pinnola(a)telecomitalia.it<mailto:andrea.pinnola@telecomitalia.it>>, "Yanick Pouffary (gmail)" <yanick.pouffary(a)gmail.com<mailto:yanick.pouffary@gmail.com>>, "Jerry Zhu (Wenjie)" <jerry.zhuwenjie(a)huawei.com<mailto:jerry.zhuwenjie@huawei.com>>, Likepeng <likepeng(a)huawei.com<mailto:likepeng@huawei.com>>, Dave Milham <dmilham(a)tmforum.org<mailto:dmilham@tmforum.org>>, Banzi Massimo <massimo.banzi(a)telecomitalia.it<mailto:massimo.banzi@telecomitalia.it>>, Robin Mersh <rmersh(a)broadband-forum.org<mailto:rmersh@broadband-forum.org>>, Hui Li <hui.li(a)huawei.com<mailto:hui.li@huawei.com>>, "Bob Cohen" <bcohen(a)tmforum.org<mailto:bcohen@tmforum.org>>, "Michael Behringer (mbehring)" <mbehring(a)cisco.com<mailto:mbehring@cisco.com>>, Stephen Fratini <stephen.fratini(a)ericsson.com<mailto:stephen.fratini@ericsson.com>>, "jean-marie.calmel(a)oracle.com<mailto:jean-marie.calmel@oracle.com>" <jean-marie.calmel(a)oracle.com<mailto:jean-marie.calmel@oracle.com>>, "Masakatsu FUJIWARA" <masa.fujiwara(a)hco.ntt.co.jp<mailto:masa.fujiwara@hco.ntt.co.jp>>, "egawa(a)ieee.org<mailto:egawa@ieee.org>" <egawa(a)ieee.org<mailto:egawa@ieee.org>>, Guchong <guchong(a)huawei.com<mailto:guchong@huawei.com>>, Latif Ladid <latif.ladid(a)uni.lu<mailto:latif.ladid@uni.lu>>, "Pekka.Olli(a)teliasonera.com<mailto:Pekka.Olli@teliasonera.com>" <pekka.olli(a)teliasonera.com<mailto:pekka.olli@teliasonera.com>>, "robert.bohn(a)nist.gov<mailto:robert.bohn@nist.gov>" <robert.bohn(a)nist.gov<mailto:robert.bohn@nist.gov>>, "Richard.Hughes-Jones(a)dante.net<mailto:Richard.Hughes-Jones@dante.net>" <Richard.Hughes-Jones(a)dante.net<mailto:Richard.Hughes-Jones@dante.net>>, "alan.sill(a)ttu.edu<mailto:alan.sill@ttu.edu>" <alan.sill(a)ttu.edu<mailto:alan.sill@ttu.edu>>, Manzalini Antonio <antonio.manzalini(a)telecomitalia.it<mailto:antonio.manzalini@telecomitalia.it>> Subject: Invitation to the joint SDOs/Fora Workshop (4th June at TMF Week in Nice): on Industry Harmonization for Unified Standards on AMC (Autonomics), SDN, NFV, 5G, .. Dear all, I am writing to invite you to our next "joint SDOs/Fora Workshop on SDOs/Fora Industry Harmonization for Unified Standards on AMC (Autonomic Management & Control), SDN, NFV, 5G, ...: from Silo approach to Cross-SDO Combined Approach". We are glad to be hosted by TMF and we appreciate and thank TMF for agreeing to host the workshop again this year during the TMF Week in June in Nice, France, on the 4th of June. Our plan is to go for a one day workshop like we did last year. We are now inviting various SDOs/Fora to be represented at the workshop. I have also included NIST and OGF who had indicated interest to join other SDOs/Fora in such joint SDOs/Fora discussions. Draft Agenda Items (more elaborate agenda will follow): 1. Present and discuss the status of the joint SDOs/Fora White Paper (first draft was presented at IEEE Globecom), which is aimed at capturing the issues requiring cross SDO/Fora or Joint-SDO harmonization efforts by two or more groups in some coordinated fashion (e.g. bilaterally, etc), including taxonomy harmonization on architectural models, etc. 2. To give each SDO/Fora the opportunity to provide summary update others on roadmaps and ideas they think better synergies or harmonization efforts with other groups could be pursued. These ideas for potential harmonization or synergies will also be added to the white paper. 3. Planning for Globecom 2015, to present updates of the joint SDOs/White Paper during Globecom 2015 in San Diego, California, and the concrete actions and items the SDOs/Fora will be taking (drawing from the white paper) on harmonization of standards. Publications and subsequent publications of the White Paper in the future. Regarding SDN, I would like to draw your attention to the paper by Joel Halpern on "Standards Collisions Around SDN", published in the IEEE Magazine on Communications Standards. We are also inviting such people to join the discussions at the workshop in June, so that we update the joint SDOs/Fora White Paper accordingly. I attach the Report from the workshop we had last year. Best Regards, Ranganai ------------------------------------------------------------------------------ On Tuesday, January 20, 2015 11:46 AM, Ranganai Chaparadza <ran4chap(a)yahoo.com<mailto:ran4chap@yahoo.com>> wrote: Dear all, Greetings in the New Year and Wishing you all a Happy and Prosperous 2015! I am sending you the updates from IEEE Globecom 2014 (Austin, Texas), where we presented the joint SDOs/Fora White Paper on Industry Harmonization for Unified Standards on SDN, NFV, Autonomic Management & Control (AMC), 5G, ... Thanks to all panelists, the presentations and discussions at Globecom were very well received. Very good discussions and conclusions on how to keep progressing the Initiative on Industry Harmonization for Unified Standards on SDN, NFV and AMC. Here are the main points we agreed at Globecom 2014 on how to progress things. In a nutshell: 1. We agreed to try to use a Special IEEE Communication Magazine on Standardization (called Communications Standards Supplement) for publishing the joint SDOs/Fora White Paper, to reach a large community. That means as the joint SDOs/Fora White Paper will be maintained as a living document (we will keep updating it), we would want to try to keep publishing all subsequent versions of the White Paper using the IEEE Communications Magazine of Standards. With support of John, Steven, Mehmet, and Tayeb, where necessary, I will check with IEEE on the possibility to make use of this Communications Magazine for publishing and updating the joint SDOs/Fora White Paper. 2. We will arrange for the next joint SDOs/Fora Workshop as follow-up to Globecom 2014 and as follow-up to the joint SDO/Fora Workshop we had in Nice last year, which was hosted by TMF in June 2014. We will check with the SDOs/Fora to see where and when we can co-locate the Workshop with a meeting of one of the SDOs. We could go for the same arrangement like last year, i.e. to request TMF to host the workshop. We start checking things now. In the meantime we will also keep collecting input to the White Paper and continue editing it with John and Tayeb. In case some of you may want to access a lot of interesting Industry Forum Slides presented at Globecom: Here are the details for downloading Slides: Industry Program Presentations Those presentations made available by industry speakers can be found at http://goo.gl/gj9KIG<http://www.cvent.com/events/mproc.aspx?m=0f7a501d-d223-4bad-84c1-549e432aa0…> for download until Saturday, 31 January 2015. Enter the password: industry2014 to access these presentations. Pictures from IEEE GLOBECOM 2014 Day 1 https://www.facebook.com/ media/set/?set=a. 10152896821128624.1073741870. 46438058623&type=3<https://www.facebook.com/media/set/?set=a.10152896821128624.1073741870.4643…> Day 2 https://www.facebook.com/ media/set/?set=a. 10152900837838624.1073741871. 46438058623&type=3<https://www.facebook.com/media/set/?set=a.10152900837838624.1073741871.4643…> Day 3 https://www.facebook.com/ media/set/?set=a. 10152903631903624.1073741872. 46438058623&type=3<https://www.facebook.com/media/set/?set=a.10152903631903624.1073741872.4643…> Day4 https://www.facebook.com/ media/set/?set=a. 10152905793088624.1073741873. 46438058623&type=3<https://www.facebook.com/media/set/?set=a.10152905793088624.1073741873.4643…> Thanks, Best Regards, Ranganai ------------------------------------------------------------------------------------------------ On Monday, December 8, 2014 11:55 AM, Ranganai Chaparadza <ran4chap(a)yahoo.com<mailto:ran4chap@yahoo.com>> wrote: Hi Steven, Manish, all, Great. Thanks Steven for this very good input to the topic of Open-source and Standardization. Together with Tayeb and John, we will add a section to the White Paper that presents the Perspectives and Recommendations concerning Open-Source and Standardization. Manish Patil (Dell) is chair of the OMG SDN WG, and the subject of Open-Source and open Standards is being discussed in his WG. Manish will be at Globecom (will join panel) and so we will discuss with him after the Panel session to ask OMG SDN WG to provide input on this subject as well into the corresponding section in the white paper. The paper from Steven will also be added to the references in white paper and in the section on this subject in the white paper. @Steven: By the way we encouraged Tarik Taleb who is charing the workshop at Globecom on "Telecommunication Standards: From Research to Standards" to invite their participants to our Industry Forum Sessions IF-12 and IF-24, and he finds this very good to encourage the participants to join the joint SDOs/Fora sessions and learn more on how to contribute to the SDOs/Fora. IF-12: SDN, NFV, Autonomic Management & Control (AMC) of Networks and Services, and IPv6, as Complementary Enablers for 5G Wednesday 10th December: 16:15 – 18:00 Joint SDOs/Fora White Paper Slot: IF-24: Industry Harmonization for Unified Standards on SDN, NFV, Autonomic Management & Control (AMC), 5G, Unified Management of Fixed/Mobile Networks Thursday 11th December: 16:15 – 18:00 See you soon. Best regards, Ranganai ------------------------------------------------------------------------------------------------------------------------------------------------- Hi Ranganai, Just looking at the suggested topics for the Wednesday Session, and noticed you were looking for something about open source and standards to be included. As it happens I have a paper on this topic that I am presenting during a Monday Workshop session as well. I’ve attached a copy for those interested in this specific topic. See you in Austin! best regards Steven Wright, MBA, PhD, JD. NFV & SDN Industry Engagement Standards & Industry Alliances AT&T Services Inc. 1057 Lenox Park Blvd NE, STE 4D28 Atlanta, GA 30319 P: 404.499.7030 sw3588(a)att.com<mailto:sw3588@att.com> @DrStevenAWright www.linkedin.com/in/drstevenawright/<http://www.linkedin.com/in/drstevenawright/> Hide message history From: Ranganai Chaparadza [mailto:ran4chap@yahoo.com] Sent: Sunday, November 30, 2014 12:06 PM To: georgedobrowski(a)mail01.huawei.com<mailto:georgedobrowski@mail01.huawei.com>; BEN MERIEM Tayeb IMT/OLN; Kenneth Dilbeck; WRIGHT, STEVEN A; John Strassner; John Strassner; Klaus Martiny; STEFAN ENGEL-FLECHSIG; Klaus Moschner; manish_patil(a)dell.com<mailto:manish_patil@dell.com>; Mehmet Ulema; Takashi Egawa; FRANCISCO JAVIER RAMON SALGUERO; Latif Ladid; Ciprian Popoviciu; Corbi Cecilia Maria; Christiantoche Toche; Niranth Amogh; Chenshan (Sunny); 'Zoltán Lajos Kis'; Pinnola Andrea; Yanick Pouffary (gmail); Jerry Zhu (Wenjie); Likepeng; Dave Milham; Banzi Massimo; Robin Mersh; Hui Li; Bob Cohen; Michael Behringer (mbehring); Stephen Fratini; jean-marie.calmel(a)oracle.com<mailto:jean-marie.calmel@oracle.com>; Masakatsu FUJIWARA; egawa(a)ieee.org<mailto:egawa@ieee.org>; Guchong; Latif Ladid; Pekka.Olli(a)teliasonera.com<mailto:Pekka.Olli@teliasonera.com> Subject: Re: The Draft of the joint SDOs/Fora White Paper and Template soliciting contributions from your Groups Dear all, As Globecom is approaching, I am sending you the Industry Forum Sessions Program in case some of you would like to join us both in the sessions IF12 and IF24 (joint SDOs/Fora White Paper Draft presentation) if you happen to attend Globecom. There might be other sessions in the program you may find interesting ofcourse, including Demos, technical articles sessions in the main program. The larger Globecom program is available here:http://globecom2014.ieee-globecom.org/ For those of you who represent individual SDO/Fora Groups, feel free to send me any updates (even in form of slides if you have any recent updated slides) on your group's activities, as we will summarize what individual groups are doing w.r.t. SDN, NFV, AMC, etc, as part of the living document (white paper) report. Otherwise we will provide summary on the basis of our TMF hosted Nice June Workshop report, and you can send us your updates any time later, even after Globecom. We will share a summary report after Globecom. Thanks to all panelists and all of you. Best Regards, Ranganai On Sunday, September 28, 2014 11:29 PM, Ranganai Chaparadza <ran4chap(a)yahoo.com<mailto:ran4chap@yahoo.com>> wrote: Dear all, Greetings to you all. We hope you had a good summer break. We are sending you the Draft of the joint SDOs/Fora White Paper we have been structuring and preparing for compiling the contributions from the various SDOs/Fora Groups. Please find attached a clean version of the Draft (makes it easier to read through) and one with track changes. We kept the list of persons who were involved in Nice, but we will be adding more names and will probably have to move the Table of contributors to the end of the paper (as it will grow). Individuals may simply provide comments on some points either directly to us the editors or through their group's collective contributions. Please find attached Template your Group can use to provide us with some input. You will notice that in chapter 11, each Group is allocated a section in which we will put their brief summaries. Any input, including indications of some plans will be fine. The White Paper will be maintained as a living document, the groups will keep updating it. With co-editors: Tayeb, John and Steven, we will put efforts to consolidate all the input as we receive the inputs. We will keep you updated with successive versions of the paper. You have some time to compile input. As we arranged earlier, the first version of the joint SDOs/Fora White paper will be presented at Globecom in December (on the 10th and 11th), Texas, Austin. The panel at Globecom will present on behalf of all the SDOs/Fora, but we encourage people to promote the the White Paper in their organizations as well as participating to the Globecom Industry Forum Sessions in which the paper will be jointly presented (if they can, or they can raise awareness to people from various organizations who will be attending Globecom). For promoting the paper, it may be good to wait for the stable version to come later. I will send more details on the Final Program of Globecom and Indications of the many interesting Industry Forum Sessions that will cover other topics and technologies. Best Regards, Ranganai <http://buy.norton.com/specialoffers?VENDORID=YAHOO> * IEEE- Open Source and Standards-final submission .pdf Download<https://us-mg6.mail.yahoo.com/neo/launch?.rand=81u0lks6p73at#>View<https://us-mg6.mail.yahoo.com/neo/launch?.rand=81u0lks6p73at#> Reply<https://us-mg6.mail.yahoo.com/neo/launch?.rand=81u0lks6p73at#>, Reply All<https://us-mg6.mail.yahoo.com/neo/launch?.rand=81u0lks6p73at#> or Forward<https://us-mg6.mail.yahoo.com/neo/launch?.rand=81u0lks6p73at#> | More<https://us-mg6.mail.yahoo.com/neo/launch?.rand=81u0lks6p73at#> me To WRIGHT, STEVEN A georgedobrowski(a)mail01.huawei.com<mailto:georgedobrowski@mail01.huawei.com> BEN MERIEM Tayeb IMT/OLN Kenneth Dilbeck John Strassnerand 32 more... <https://us-mg6.mail.yahoo.com/neo/launch?.rand=81u0lks6p73at#> Dec 8, 2014 Hi Steven, Manish, all, Great. Thanks Steven for this very good input to the topic of Open-source and Standardization. Together with Tayeb and John, we will add a section to the White Paper that presents the Perspectives and Recommendations concerning Open-Source and Standardization. Manish Patil (Dell) is chair of the OMG SDN WG, and the subject of Open-Source and open Standards is being discussed in his WG. Manish will be at Globecom (will join panel) and so we will discuss with him after the Panel session to ask OMG SDN WG to provide input on this subject as well into the corresponding section in the white paper. The paper from Steven will also be added to the references in white paper and in the section on this subject in the white paper. @Steven: By the way we encouraged Tarik Taleb who is charing the workshop at Globecom on "Telecommunication Standards: From Research to Standards" to invite their participants to our Industry Forum Sessions IF-12 and IF-24, and he finds this very good to encourage the participants to join the joint SDOs/Fora sessions and learn more on how to contribute to the SDOs/Fora. IF-12: SDN, NFV, Autonomic Management & Control (AMC) of Networks and Services, and IPv6, as Complementary Enablers for 5G Wednesday 10th December: 16:15 – 18:00 Joint SDOs/Fora White Paper Slot: IF-24: Industry Harmonization for Unified Standards on SDN, NFV, Autonomic Management & Control (AMC), 5G, Unified Management of Fixed/Mobile Networks Thursday 11th December: 16:15 – 18:00 See you soon. Best regards, Ranganai Hide message history On Sunday, December 7, 2014 4:59 PM, "WRIGHT, STEVEN A" <sw3588(a)att.com<mailto:sw3588@att.com>> wrote: Hi Ranganai, Just looking at the suggested topics for the Wednesday Session, and noticed you were looking for something about open source and standards to be included. As it happens I have a paper on this topic that I am presenting during a Monday Workshop session as well. I’ve attached a copy for those interested in this specific topic. See you in Austin! best regards Steven Wright, MBA, PhD, JD. NFV & SDN Industry Engagement Standards & Industry Alliances AT&T Services Inc. 1057 Lenox Park Blvd NE, STE 4D28 Atlanta, GA 30319 P: 404.499.7030 sw3588(a)att.com<mailto:sw3588@att.com> @DrStevenAWright www.linkedin.com/in/drstevenawright/<http://www.linkedin.com/in/drstevenawright/> From: Ranganai Chaparadza [mailto:ran4chap@yahoo.com] Sent: Sunday, November 30, 2014 12:06 PM To: georgedobrowski(a)mail01.huawei.com<mailto:georgedobrowski@mail01.huawei.com>; BEN MERIEM Tayeb IMT/OLN; Kenneth Dilbeck; WRIGHT, STEVEN A; John Strassner; John Strassner; Klaus Martiny; STEFAN ENGEL-FLECHSIG; Klaus Moschner; manish_patil(a)dell.com<mailto:manish_patil@dell.com>; Mehmet Ulema; Takashi Egawa; FRANCISCO JAVIER RAMON SALGUERO; Latif Ladid; Ciprian Popoviciu; Corbi Cecilia Maria; Christiantoche Toche; Niranth Amogh; Chenshan (Sunny); 'Zoltán Lajos Kis'; Pinnola Andrea; Yanick Pouffary (gmail); Jerry Zhu (Wenjie); Likepeng; Dave Milham; Banzi Massimo; Robin Mersh; Hui Li; Bob Cohen; Michael Behringer (mbehring); Stephen Fratini; jean-marie.calmel(a)oracle.com<mailto:jean-marie.calmel@oracle.com>; Masakatsu FUJIWARA; egawa(a)ieee.org<mailto:egawa@ieee.org>; Guchong; Latif Ladid; Pekka.Olli(a)teliasonera.com<mailto:Pekka.Olli@teliasonera.com> Subject: Re: The Draft of the joint SDOs/Fora White Paper and Template soliciting contributions from your Groups Dear all, As Globecom is approaching, I am sending you the Industry Forum Sessions Program in case some of you would like to join us both in the sessions IF12 and IF24 (joint SDOs/Fora White Paper Draft presentation) if you happen to attend Globecom. There might be other sessions in the program you may find interesting ofcourse, including Demos, technical articles sessions in the main program. The larger Globecom program is available here:http://globecom2014.ieee-globecom.org/ For those of you who represent individual SDO/Fora Groups, feel free to send me any updates (even in form of slides if you have any recent updated slides) on your group's activities, as we will summarize what individual groups are doing w.r.t. SDN, NFV, AMC, etc, as part of the living document (white paper) report. Otherwise we will provide summary on the basis of our TMF hosted Nice June Workshop report, and you can send us your updates any time later, even after Globecom. We will share a summary report after Globecom. Thanks to all panelists and all of you. Best Regards, Ranganai On Sunday, September 28, 2014 11:29 PM, Ranganai Chaparadza <ran4chap(a)yahoo.com<mailto:ran4chap@yahoo.com>> wrote: Dear all, Greetings to you all. We hope you had a good summer break. We are sending you the Draft of the joint SDOs/Fora White Paper we have been structuring and preparing for compiling the contributions from the various SDOs/Fora Groups. Please find attached a clean version of the Draft (makes it easier to read through) and one with track changes. We kept the list of persons who were involved in Nice, but we will be adding more names and will probably have to move the Table of contributors to the end of the paper (as it will grow). Individuals may simply provide comments on some points either directly to us the editors or through their group's collective contributions. Please find attached Template your Group can use to provide us with some input. You will notice that in chapter 11, each Group is allocated a section in which we will put their brief summaries. Any input, including indications of some plans will be fine. The White Paper will be maintained as a living document, the groups will keep updating it. With co-editors: Tayeb, John and Steven, we will put efforts to consolidate all the input as we receive the inputs. We will keep you updated with successive versions of the paper. You have some time to compile input. As we arranged earlier, the first version of the joint SDOs/Fora White paper will be presented at Globecom in December (on the 10th and 11th), Texas, Austin. The panel at Globecom will present on behalf of all the SDOs/Fora, but we encourage people to promote the the White Paper in their organizations as well as participating to the Globecom Industry Forum Sessions in which the paper will be jointly presented (if they can, or they can raise awareness to people from various organizations who will be attending Globecom). For promoting the paper, it may be good to wait for the stable version to come later. I will send more details on the Final Program of Globecom and Indications of the many interesting Industry Forum Sessions that will cover other topics and technologies. Best Regards, Ranganai

1 0

minutes from today's NSI conf call...
by Guy Roberts 19 Feb '15

19 Feb '15

... are attached. _____________________________________________________________________ Guy Roberts PhD Senior Transport Network Architect GEANT Limited Email: guy.roberts(a)dante.net<mailto:guy.roberts@dante.net> Tel: +44 (0)1223 371316 Mob: +44 (0)7881 336417 GEANT Limited is part of the GÉANT Association Networking. Services. People Learn more at: www.geant.org<http://www.geant.org/> and www.dante.net<http://www.dante.net/> GEANT Limited registered in England & Wales. Registration Number 2806796. Registered Office - City House, 126-130 Hills Road, Cambridge CB2 1PQ _____________________________________________________________________

1 0

Koning et. al. : Topology exchange presentation - to be discussed during the call today
by Miroslav Zivkovic 18 Feb '15

18 Feb '15

See you in a moment. Miroslav

1 0

NSI gfd release roadmap 2015
by Guy Roberts 12 Feb '15

12 Feb '15

Hello All, I have updated the NSI roadmap for gfd publications in 2015. This is available here: https://redmine.ogf.org/dmsf_files/13401 Guy _____________________________________________________________________ Guy Roberts PhD Senior Transport Network Architect GEANT Limited Email: guy.roberts(a)dante.net<mailto:guy.roberts@dante.net> Tel: +44 (0)1223 371316 Mob: +44 (0)7881 336417 GEANT Limited is part of the GÉANT Association Networking. Services. People Learn more at: www.geant.org<http://www.geant.org/> and www.dante.net<http://www.dante.net/> GEANT Limited registered in England & Wales. Registration Number 2806796. Registered Office - City House, 126-130 Hills Road, Cambridge CB2 1PQ _____________________________________________________________________

1 0

NSI topo distribution proposals
by Guy Roberts 11 Feb '15

11 Feb '15

Hello All, As you know, we have a deadline of the end of February for submission of proposals for the NSI topology distribution mechanism in preparation for a vote in the second week in March. I would like to give each of the 3 authors a chance to present their proposals to the working group, so I have set up the following 3 NSI conf calls: Wednesday 18th Feb - Ralph Koning Wednesday 25th Feb - Henrik Thostrup Jensen Wednesday 4th Mar - John MacAuley Proposals are be available to download in advance here: https://redmine.ogf.org/dmsf/nsi-wg?folder_id=6526 Regards, Guy _____________________________________________________________________ Guy Roberts PhD Senior Transport Network Architect GEANT Limited Email: guy.roberts(a)dante.net<mailto:guy.roberts@dante.net> Tel: +44 (0)1223 371316 Mob: +44 (0)7881 336417 GEANT Limited is part of the GÉANT Association Networking. Services. People Learn more at: www.geant.org<http://www.geant.org/> and www.dante.net<http://www.dante.net/> GEANT Limited registered in England & Wales. Registration Number 2806796. Registered Office - City House, 126-130 Hills Road, Cambridge CB2 1PQ _____________________________________________________________________

1 0