cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

313
Views
4
Helpful
22
Replies
khgrant
Cisco Employee

Inserting new VNF in NSO/VMS

Hi Experts

What is the best way for Tail-F to support the insertion of additional virtual network functions in a virtual topology?

Say customer has running “CSR — ASA” and decides to add IPS to make it “CSR — IPS — ASA”. Can Tail-F do this without destroying the existing VNFs, which may have running state in them? Can a service model change its topology like that?

1 ACCEPTED SOLUTION

Accepted Solutions
khgrant
Cisco Employee

I was thinking about a scenario like the one you described a while back. I think it is possible to make dynamic changes to the VNF forwarding graph on the fly but IMO it requires interaction with the VIM layer.

I have a NFV service chain Yang model which allows a list of VNFs to be inserted into the service chain. So, each VNF has a “left” side and “right” side interface,  E.g:

    List vnf {

        Key name;

        Leaf name {

          type leafref {

            path "/ncs:devices/ncs:device/ncs:name";

          }

          tailf:info "VNF name";

        }

        leaf left-intf {

          tailf:info “VNF interface facing source zone";

          type string;

        }

        leaf left-ip-addr {

          type inet:ip-address;

        }

        leaf lef-mask {

          type union {

            type string {

              tailf:info "CIDR representation";

            }

            type inet:ip-address {

              tailf:info "subnet mask in dotted representation";

            }

          }

        }

        leaf right-intf {

          tailf:info “VNF interface facing target zone";

          type string;

        }

        leaf right-ip-addr {

          type inet:ip-address;

        }

        leaf right-mask {

          type union {

            type string {

              tailf:info "CIDR representation";

            }

            type inet:ip-address {

              tailf:info "subnet mask in dotted representation";

            }

          }

        }

   — snip —

}

Next, remember before this VNF can be service chained by NSO, I’ve to spin it up the individual VNFs via Openstack and/or ESC. For each VNF, we need to define the respective neutron nets/subnets for it to associate its interfaces with.

-neutron net 1 – VNF1 — neutron net2 — VNF2 — neutron net3 —

Now, if we want to insert a new VNF3 in between VNF1 and VNF2, we have to re-work the neutron nets associations of VNF1, VNF2 and VNF3. Basically, we have to invoke Openstack Nova as follow:

1. Create a new neutron net 2b

2. Disassociate VNF2's left interface from neutron net2 and associate it with neutron net2b

3. Associate VNF3s left interface with neutron net2 and right interface with neutron net2b

So, the new VNF graph looks like this:

-neutron net 1 – VNF1 — neutron net2 — *VNF3* — neutron net2b -- VNF2 — neutron net3 —

I think the NSO service model logic can be written to handle the above but the easiest way is to reboot the service with the new VNF graph.


View solution in original post

22 REPLIES 22
khgrant
Cisco Employee

I was thinking about a scenario like the one you described a while back. I think it is possible to make dynamic changes to the VNF forwarding graph on the fly but IMO it requires interaction with the VIM layer.

I have a NFV service chain Yang model which allows a list of VNFs to be inserted into the service chain. So, each VNF has a “left” side and “right” side interface,  E.g:

    List vnf {

        Key name;

        Leaf name {

          type leafref {

            path "/ncs:devices/ncs:device/ncs:name";

          }

          tailf:info "VNF name";

        }

        leaf left-intf {

          tailf:info “VNF interface facing source zone";

          type string;

        }

        leaf left-ip-addr {

          type inet:ip-address;

        }

        leaf lef-mask {

          type union {

            type string {

              tailf:info "CIDR representation";

            }

            type inet:ip-address {

              tailf:info "subnet mask in dotted representation";

            }

          }

        }

        leaf right-intf {

          tailf:info “VNF interface facing target zone";

          type string;

        }

        leaf right-ip-addr {

          type inet:ip-address;

        }

        leaf right-mask {

          type union {

            type string {

              tailf:info "CIDR representation";

            }

            type inet:ip-address {

              tailf:info "subnet mask in dotted representation";

            }

          }

        }

   — snip —

}

Next, remember before this VNF can be service chained by NSO, I’ve to spin it up the individual VNFs via Openstack and/or ESC. For each VNF, we need to define the respective neutron nets/subnets for it to associate its interfaces with.

-neutron net 1 – VNF1 — neutron net2 — VNF2 — neutron net3 —

Now, if we want to insert a new VNF3 in between VNF1 and VNF2, we have to re-work the neutron nets associations of VNF1, VNF2 and VNF3. Basically, we have to invoke Openstack Nova as follow:

1. Create a new neutron net 2b

2. Disassociate VNF2's left interface from neutron net2 and associate it with neutron net2b

3. Associate VNF3s left interface with neutron net2 and right interface with neutron net2b

So, the new VNF graph looks like this:

-neutron net 1 – VNF1 — neutron net2 — *VNF3* — neutron net2b -- VNF2 — neutron net3 —

I think the NSO service model logic can be written to handle the above but the easiest way is to reboot the service with the new VNF graph.


khgrant
Cisco Employee

> I think the NSO service model logic can be written to handle the above but the easiest way is to reboot the service with the new VNF graph.

+1. Changing the service chain like that is better served by deleting the current one, and creating a new one.

khgrant
Cisco Employee

This is exactly what I was trying to achieve. Though, the VNF that is inserted need not be any arbitrary VNF (it can be a pre-defined or fixed VNF). In other words, VNF3 in your example is an “optional” VNF in the service model and can be added later, but we already predefined what VNF3 is from the onset. Vice versa, it can be removed from the service model by “turning it off”.

Wondering if anyone has any smart way to do this that is in line with Tail-F original design principles.

khgrant
Cisco Employee

Rajiv, you have a point. I was thinking that too.

On the other hand, in the physical world, customer have the ability to add an Email security or Web Security or IDS without bringing down all services. For us to address mission-critical services, we might need an approach that does not nuke the service and rebuild.

Can we extend our L2/L3VPN approach (where we can add sites) to this?

khgrant
Cisco Employee

If the new VNF you’re talking about is the likes of Web Security, IPS, Malware scanning which can be deployed flexibly in passive l2 mode (one arm mode) and does not need to be inline from the topology perspectives, then I think we do not need to rebuild the existing service.

For example:

             VNF3 (IPS)

                |

  VNF1     —————+————— VNF2

  (CSR1KV)            (ASAv)

NSO can spin up the new VNF3 via ESC and attach it to the existing neutron net between VNF1 and VNF2. Also, there would be no changes required to existing VNF1 and VNF2 service configuration wise.

khgrant
Cisco Employee

Yeah, I get what you mean. That is a worst case scenario approach as it burns resources. Say if most of the customers don't turn on all the options there will be a lot of idle VNF that are just being points of failures.

khgrant
Cisco Employee

Looking at your email again maybe I misunderstood.

If we can insert one arm VNF without rebuilding, that is a good start. Is this by putting the VNF in the original service model or by switching to another service model with that VNF?

khgrant
Cisco Employee

I believe we can achieve that simply by modifying the existing service — the model should cater for a list of VNFs (e.g 2 from the start, and add 1 later on which will call re-deploy to invoke ESC to spin up the additional VM).

khgrant
Cisco Employee

+1

Optimizing for the ability to dynamically extend or shrink chains is technically challenging, and overkill IMHO

Unless the requirement from customer is to have zero down time on e.g VPNs when this type of change is performed - which is a very difficult requirement to meet.

khgrant
Cisco Employee

It is mainly to cater for enterprise-grade VMS. It is not only for zero downtime, but also to not lose the state information kept in the VMs, eg.

Emails quarantined in Email security, etc

khgrant
Cisco Employee

if we have to compute a new topology in order to bring up a new VNF in a service, we could apply the resulting config changes to the existing VNF’s and add the new VNF to this topology. That could be a meet in the middle scenario, where you don’t reboot the existing VNFs or full redeploy them.

khgrant
Cisco Employee

Stacked service model is a requirement.  Just encountered this with Verizon yesterday.  They have an orchestration platform that they want to use to orchestrate the creation of the VNF (CSR running in VMware on

UCS) while they call our VMS platform to orchestrate the remote CPE and its attachment to the VNF (CSR) via IPSec.  They own the global service representation while VMS owns a service model with a subset of components.

What I'd like to see is the Tenant VLAN established as a base service model.  With that as the base service model, I can stack new service models that are pseudo independent of one another except for their reference to the base service model.  On the Tenant VLAN I want to attach a session border controller,  IWAN PfR master controller, cache server, etc.  These functions are not in-line. They are independent systems installed to enhanced the capabilities of the customer network. 

In both cases, I assume the VPN exists (e.g. Cloud VPN, DMVPN, FlexVPN, MPLS VPN, ...).  I just want to attach new services from a pick-list into the base service model representation of the Tenant VLAN.

khgrant
Cisco Employee

Fyi, I¹m exploring a residential vCPE model as well with a local telco here in Singapore.

The baseline VNF would be a basic vCPE like open-wrt and they will allow their IPTV subscribers to order add-ons such as cloud DVRs, vSTBs and insert these into the tenant VLAN.

khgrant
Cisco Employee

On the other hand, in the physical world, customer have the ability to add
an Email security or Web Security or IDS without bringing down all
services.

Ummm...you perhaps mean the existing physical devices don't need to be restarted to insert a new physical device in the chain. However, that change _usually_ does impact the services and the "state" held by the existing devices (depending on how long it takes to make the physical and logical

change on existing devices) .

For ex, if firewall is holding the state and connected to the IPS, then inserting IDS (say) in between would _likely_ require changes on both existing devices.

Create
Recognize Your Peers
Content for Community-Ad