When starting a delivery project in NSO, it's important to get the right skill sets together to ensure a successful outcome. This document outlines the appropriate level of expertise and familiarity that each role should have with a particular skill set or knowledge domain. ... View more

created by rogaglia NSO is a fantastic tool for multi-vendor firewall rules management. I guess this is no surprise for anyone who is familiar with the internal machinery of the tool. With NSO 4.4, one new feature was added to allow much easier firewall rules management using NSO templates and I want to discuss this point in this article. Why is firewall rules managing complicated? The main issue has to do with ordering. Basically, a firewall rule is a list of complex objects where a number of restrictions are imposed regarding the order of its elements. Additionally, the elements that make the rule are typically from different service instances and many times from different service types. One example could be your firewall rules towards the Internet. Some rules are added by instance1 of type service1 but some from instance123 from service2, etc. etc. We will call this requirement "multi-tenancy". One aspect that is very hard about firewall rule management is to perform compliance reporting. All the different service instances that are part of a firewall rule list have their life-cycle activities (creation, modifications or deletions) but the restrictions for the order on the rule lists need to be preserved all the time. Moreover, the security compliance team needs to receive a report of compliance from the system at anytime. Managing firewall rules, the NSO way: NSO service manager and FASTMAP algorithms allow you "off the shelf" to support "multi-tenancy" and compliance reporting. However, the most important feature in this space is that NSO allows you to be extremely precise on how you wish to manage the order of your firewall rules. It all starts with standard YANG. When we look at RFC7950 and how YANG can manage order in lists, we need to study the "ordered-by" statement (section 7.7.7 ) that can take two values: - "ordered-by system": This is the default behavior for a list. It basically means that NSO will choose the list order. In NSO case, it will use the "natural" order for the lists keys. This option means that the user does not have any control on thus is typically not adequate for firewall rule management. - "ordered-by user": In this case, the order in the list is 100% managed by the user. This will be the option when working with list of firewall rules. I am going to use for example a Checkpoint device. If we look at the NSO checkpoint NED, we can find the definition of the list of access-rules as an "ordered-by user" list: // access-layer * / access-rule * list access-rule {        ordered-by user;      key name;      leaf name {             type string;      }      uses access-rule; } As an "ordered-by user" list, I can use the NSO CLI command "move" to organize the list in any way that I see fit: admin@ncs% move devices device checkpoint-lab config checkpoint-gaiaos_rest:access-layer new_test access-rule SERVICE_testnew Possible completions:   after  before  first  last If we chose one option: admin@ncs% move devices device checkpoint-lab config checkpoint-gaiaos_rest:access-layer new_test access-rule SERVICE_testnew first [ok][2017-03-27 11:49:29] [edit] admin@ncs% What we will see is that the NSO NED will use the device API to configure the new order. In this case, Checkpoint provides us a "position" statement that we can match accordingly ("top" = "first"): admin@ncs% commit dry-run outformat native native {     device {         name checkpoint-lab         data POST https://10.147.46.109:443/web_api/delete-access-rule              {                  "name" : "SERVICE_testnew",                  "layer" : "new_test"              }              POST https://10.147.46.109:443/web_api/add-access-rule              {                "comments": "",                "service": "SERVICE_SRV_GROUP_testnew",                "name": "SERVICE_testnew",                "destination": "Any",                "action": "Drop",                "position": "top",                "source": "SERVICE_GROUP_testnew",                "custom-fields": {                  "field-1": "",                  "field-2": "",                  "field-3": ""                },                "track": "None",                "layer": "new_test",                "enabled": true              }     } } [ok][2017-03-27 11:49:45] [edit] admin@ncs% The use of these "move" options are also available when writing a NSO service, particularly in a service template. Particularly, if I want to insert new rules always on top of the access-rule list, I can use:  <access-rule insert="first"> Or if I want new rules to be created before the final "Cleanup Rule" (deny any any): <access-rule insert="before" value="Cleanup Rule"> NSO Guard for "ordered-by user" lists, a new NSO 4.4 feature: All the features that we have seen so far were native NSO features for a long time. However, in order to address all the restrictions in firewall rule management, they were not enough. Imagine the example above, where a service template has the following insert request:  <access-layer xmlns=" http://tail-f.com/ned/checkpoint-gaiaos_rest ">      <name>My layer</name>      <access-rule insert="first">           <name>SERVICE_{/name}</name>           <source>                <name>SERVICE_GROUP_{/name}</name>           </source>           <destination>                <name>Any</name>           </destination>           <service>                <name>SERVICE_SRV_GROUP_{/name}</name>           </service>      </access-rule> </access-layer> So, when the add the first instance, a rule will be added on top of access-rule list. However, when you add the second service instance, the initial rule will be moved to the second place in order to give space to the new first rule. At the end of the day, there is only one possible rule (at any given time) to the top position. This means that there is only one service instance that will be "in-sync". In reality, the firewall rule requirement is not that a given rule is always in the same position but that it remains in a "zone" delimited by some specific rules. In our case, we do not really cases where the rule is as long as it is always before the "Cleanup rule" that will deny all the traffic. The guard feature in NSO 4.4. allows us to express these requirements in a simple way:           <access-rule insert="first" guard="Cleanup\ rule"> This template configuration should be interpreted as: - if the rule does not exist, it should be created in the first position of the list. - if the rule already exists, it should always be located between the first position and the "Cleanup rule". Using this new feature, multiple service instances that control the same access-rule will  be "in-sync": admin@ncs% request db-firewalls db-firewall * check-sync db-firewalls db-firewall paas_1 check-sync     in-sync true db-firewalls db-firewall paas_2 check-sync     in-sync true [ok][2017-03-27 12:09:17] [edit] admin@ncs% If we look at the "NSO development guide", we can find many additional uses of the new guard feature: • If insert="first", then the constraint is fulfilled if the element exists in the configuration before the element indicated by the guard. • If insert="last", then the constraint is fulfilled if the element exists in the configuration after the element indicated by the guard. • If insert="after", then the constraint is fulfilled if the element exists in the configuration before the element indicated by the guard, but after the element indicated by the key or value statement. • If insert="before", then the constraint is fulfilled if the element exists in the configuration after the element indicated by the guard, but before the element indicated by the key or value statement. • If the guard evaluates to an empty node-set (i.e. the node indicated by the guard does not exist in the target configuration), then the constraint is not fulfilled. Conclusion: NSO is a fantastic tool for firewall rule management, particularly in multi-vendor, multi-domain environments. With NSO 4.4, the guard feature was introduced, which makes support for complex firewall rules constrains extremely easy. Note: All these features are available for any "ordered-by user" list. Particularly, we can find similar requirements in areas such as QoS management or routing policy management. ... View more

https://www.layer123.com/nfv NFV+SDN Carrier Evolution in Silicon Valley NFV World Congress was founded in 2014 by a group of visionary and senior carrier leaders, in order to form a centre of gravity for the rapidly emerging NFV industry, and provide the right forum to accelerate innovation and support ecosystem growth. Over 1,000 delegates attending the launch event in spring 2015, growing to over 1,300 delegates in 2016, along with 50+ exhibitors and over 20 live demos. As new commercial applications and services are launched and deployed - such as SD-WAN - 2017 will see important advances in NFV+SDN+MANO. There is no let-up in the pace of innovation, with NFV now forming the cornerstone of telecom network and business transformation. In a commercial setting, the complete ecosystem is coming together again in May to advance the market, to demonstrate a critical mass of progress, and to show just what NFV+SDN can deliver to carriers and their customers. Truly neutral – with no hidden agenda – NFV World Congress is the principal platform for the industry to showcase applied innovation for production networks, as opposed to blue-sky research. Plan to meet 1,500 colleagues, leaders and activists at this centre of gravity in San Jose for the NFV+SDN+MANO network ecosystem. Location :DoubleTree Hilton - San Jose, CA USA Event Visibility Public ... View more

Open Networking Summit 2017 | Linux Conferences and Linux Events | The Linux Foundation Open Networking Summit, the industry's largest event, brings together business and technical leaders across enterprise, cloud and service providers to share learnings, highlight innovation and discuss the future of open networking and orchestration. Executives, architects, developers and operators will gather to: Hear from industry visionaries and leaders on the future of Networking beyond SDN/NFV Attend deep technical tracks on topics that are here today, tomorrow and on the horizon Learn from the use cases of your peers as consumption of Open Source Networking is the “new norm” and mandated by most Enterprise CIOs, Carrier CTOs and Cloud Executives For the past six years, ONS has united the networking industry ecosystem of network operators, both disruptive and incumbent vendors, open source projects, leading researchers and investors to discuss breaking SDN and NFV developments for immediate impact to shape the future of the networking industry. ONS 2017 is the best forum for companies to strengthen their brand, establish thought leadership, connect with both end customers and partners, showcase innovative products and drive the transformation in the emerging open source networking industry. Event Link: Open Networking Summit 2017 | Linux Conferences and Linux Events | The Linux Foundation NFVBU attendance: Song Toh #ONS2017 Location :Santa Clara Convention Center, Santa Clara CA Event Visibility Public ... View more

  Hi Team,     I created a service and it is successful. Later, user comes back and tries to change a leaf “tenantName”, I should not allow the user to change this leaf once it is set.   I thought of using opaque object for this purpose.   Any suggestions ?     With regards   Jaswanth   ... View more