Agenda: http://tools.ietf.org/agenda/87/agenda-87-nsc.html

Scribe: Carlos Pignataro


Network Service Chaining (nsc) BoF Agenda

Bof Chairs: Jim Guichard (jguichar@cisco.com) & Thomas Narten (narten@us.ibm.com)


Introduction: (5)
- BoF Chairs

• Thomas: Let's get started, we have only an hour and then a short break.
• ... you all know the Note Well. Jim will share some context on the problem, then some presentations and a bit of discussion time at the end.
• ... given our short session, we will be ruthless with the mike and allowing only a short set of questions.
• The objective is to see if there is interest. Operators will be explaining the problems they have and use cases. Also, this is not a WG forming BOF, so we will not get into whether we form a WG. It is premature to discuss that; down the road (around Vancouver time) we might want to form a WG.
• These are the three broad questions for the end:
  • 1. Is this an important problem area?
  • 2. Should IETF work towards a WG?
  • 3. Are people interested in doing the work?
• The Problem Statement comes from a document. For people that work on this space it is obvious but not for others. You might have many elements (firewall, etc) cooperating a certain way to perform a service. For example, no matter where the firewall migh be, the traffic should go through it and requirements be met. Today, these is done with layer 2 or layer 3 forwarding. Therefore, the service chain is tied to the underlying network. Once it is set up, it is really difficult to change that configuration of the deployed system.
• Additionally, there is no way to share context between elements.
• With that let me turn it over to our first presenter.
  
  
  
  

Network Based Services in Mobile Networks: (10)
- Walter Haeffner (walter.haeffner@vodafone.com)

• Walter: First of all I want to talk about network services in mobile networks. Those first slides are for those that do not know mobile networks. In this case it's an LTE cell, terminating in a service wateway, a mobile management entity, and takes care of connectivity and mobility. Behind there is a packet gatewat and together with a policy function takes care of policing. Then we have an SGI interface. It's existent is defined but not its content. What is it supporting? Connectivity to the Internet, or to operator based services (like LTE services). 
• We concentrate on Network Services (SG-LAN). These are performance enhancement boxes, firewalls, DPIs, etc.
• Here we have out packet gateway, and a vlan connecting to the other end a service environment. It could be operator based IMS or MPLS VPNs (fixed networks of enterprises), or connectivity to the Internet. Some services have proxies, firewalls, NAT devices, optimizers, load-balancers, etc. These are chained services to fullfil the requirement.
• How does this look in reality? A lot of boxes are attached to this router. Boxes have single service, other boxes multiple services. This is a very static environment, but in mobile networks we see our services are more and more complex.
• In these environments people use static routes, policy routing, and this makes the network very static and inflexible. Our requirements are of simplicitly. An operator should be able to click and choose services from a catalog and insert into the network. We are asking for much more automatism.
• We have many sources for metadata in these networks. Information in the P-GW has policy and other information including QoS and others. OTOH, it would be hard to single out a single metadata.
• Another open issue in such environment is that there is no coupling between the service itself and the network. The service does not know about network conditions. Is the network loaded or free? Someone is asking for HD-video, for example.
• This is my summary:
  • First, simplicity and speed is key in a mobile network.
  • Second, we need ways to provision these service chains easier.
  • Third: We should use metadata -- the question is which metadata and how. Future research.

Questions:

• <no questions>
  
  
  
  

Network Function Virtualization (NFV): (10)
- Diego Lopez (diego@tid.es)

• Essencially this is talking about NfV again, and how we see NfV relating to this NSC idea.
• First two slides are about NFV. I talked about this in the SDNRG session so we might skik.
• This is the essencial part. We are taking about Network Service Chainging, and in NfV we talk about Virtual Network Function for building graphs. But we are talking about this. This is what the network operator can provide to customers. We forsee forwarding graphs not limited.
• NFV Forwarding graphs virtualized will provide efficiency in space and time, resiliency, recovery proedures, agility by shortening innovation cycles. Also, provide flexibility of things being virtualized. Much more choices, and we call that expressiveness. And of course flexibility.
• We believe these are very important business models. Operators can have mutual deployments or with 3rd parties.
• This is the general architecture. Services running on top of the infrastructure. VNF providers will provide the software and requirements for connecting the components inside VNFs. The orchestration will take care of storage, compute, and networking. The network service provider can install the forwarding graph by attaching the endpoints for the service.
• Know that here we are also talking about physical networks. We acknowledge that there will be time (very long time) of co-existence. Most likely forwarding graphs will combine both physical and virtual networks.
• Challenges we see are migration and co-existence. Make free arrangements of different network functions. We would like to see a mechanism for how a network forwarding graph will be built. And we also need ways of measure and verify.
• In the mailing list there's also been discussion about whether to include multiple domains. I agree this is a requirement from the beginning. If we want to foster new collaboration that we foresee it's a requirement.
• I was asked by the chairs to prepare 3 take-aways.
  • NFV intends to bring virtualization into network functions
  • Network Service Chaining (VNFG in BFV jargon) is key in the NFV service model.
  • NFV does not intend to build standards on its own.
• We would like that the IETF takes a role here and progresses in this direction.

Questions:

• <no questions>
  
  
  
  

Enterprise use case: (10)
- Mudassir Tufail (mudassir.tufail@citi.com)

• I represent Ciri Group, one of the largets.
• The way we define services are:
  • Firewall -- today we use HW appliances. We will use distributed ones.
  • Load-balancer -- we use in two phases: external and internal. 
  • Third one is WAN acceleration. We use these in our branches.
  • Last: Traffic Monitoring and SPAN/TAP. This is really important for compliance.
• One of our biggest problems today is that the path to the appliance is too rigid and static.
• We are creating a software defined data center. We will have a ton of HW appliances with virtual appliances. You can imagine how hard it will be to manage a virtual appliance. This is why we want to make it easy for us to manage network services.
• Now, this is what we want to see. A WAN network at the top, but most importantly how we connect externally. Both externally and internally we will be using a number of services. These appliances do not talk to each other, so we need a standard on how these services talk to each other.
• My take-aways are:
  • Asset optimization -- we are moving towards virtual appliances and we want to see benefits
  • Static to flexible service enablement.
  • Complexity to simplicity. Today we are talking to all these service independently which is very complex. We hope that all of these talk to each other seamlessly.
  • Multi-vendor interop. 

Questions:

• <no questions>
  
  
  
  

Data Center use case: (10)
- Brad McConnell (bmcconne@rackspace.com)

• Good afternoon, I am _not_ Brad, I am Paul and I proxy for Brad.
• This is about the need to simplify and exchange information about the service chain
• Rack space provides a set of suite of services, managed hypervisor, etc. We have to deal with a number of topologies and overlays and underlays.
• Challenges:
  • First point: when you have a lot of vendors in hypervisor, the lowest common denominator is pretty low, and it is VLANs -- and we know the issues with that.
  • vertically integrated solutions
  • Need consistency, and I won't discuss the "SDN" piece since we all know that.
• Changing VLANs is not viable. Changing encaps in the datacenter is not viable. Prevalent technologies requires decap and encap, and we want to avod that. VXLAN to VLAN, etc., is an exercise of mapping.
• When we want STT to another not common overlay, and  more importantly we want to interoperate datacenters, we have context and we need to move metadata for that context.
• What context? There is a lot of different context to be shared: userid, OAM, Direction, pipeline stage index (visibility into the pipeline and vertical scale), version, compliance.
• You see, there is a ton of information that we pass along but we do not have a way of doing that.
• Service chaining isn;t about the encap. We would like to pass context along those pipelines to allow each Service in the chain to get that context and not have to derive it on their own their own way. For example, that a service chain receives user id. And last, let's stay focused.

Questions:

• <no questions>
  
  
  
  

Q&A/Closing: (15)
- BoF Chairs

• Thomas: At this point I'd like to open to questions and comments.
• Someone: there seems there are at least two use cases -- the graph, and the -- they should probably be divided in the same WG or in different WGs.
• Thomas: I've been to a lot of BOFs and a single comment is amazing.
• Adrian: Thank you for saying that Thomas. That was worrying me. Either means nobody cares, or everyone agrees and there is nothing to say. I would like to ask people to ask if people aling on what a service chain is.
• Thomas: I think in the alias you see that peeling the onion there is not a lot of agreement. We cannot answer that here.
• Linda: I have many questions. I see network services, and that's been used in many contexts. VPN services, etc. Citigroup has L2 to L7 services. In datacenter, we see those chained together. I see here presentations about sending traffic to another domain because you do not know how to route it. So net-net: what are those services?
• Diego: Adrian probably was right in the disagreement about what service chain is. I see the need for having mechanisms of passing packet context to build a service chain or mesh or routing or whatever you call it. How this context is derived and what is the purpose of this content is a disagreement. But the need to pass this context is a common need.
• Someone: I think there is a need for this group. Citi highlighted what I see in the security area. It's not about flexibility of passing, but about avoiding duplicate work for not classify twice. I am very supportive of this work.
• Steven, AT&T: Open Forum has the same -- I do not have the liaison.
• Someone Else: All the devices need to implement service a certain way. And there are various control planes we can use for that. We also have a lot of dataplane encapsulations. So I am not very clear on what we need to do to implement a higher level management doing the service chain. In which plane are we trying to standardize work? dataplane? control? management?
• Thomas: Maybe we do not know. What encapsulations do we have today to end context and service chain? We don't
• Same someone: We have bits in VXLAN, we have MPLS Label. I am trying to understand what is our focus. Service chain across these encaps? uniform control plane?
• Jim: These are things we need to work out if we have a WG. The purpose of today is to show that there is a problem. Seems there's a lot of interest and people to work on them. As Thomas said, we do not have all the answers.
• China Mobile: Thank you for separating use cases in mobile and fixed. We also have a draft on mobile use cases. The one comment is about linkage about network service chain to other work in IETF.
• Yet another someone: There is a desire to cross various encaps, VXLAN, VLAN, MPLS, and here is a scenario where there is a lot of opportunity to standardization. So we are loosing information when moving form one to the other encap.
• A The ForCES WG charter is to interconnect packet plus pass metadata. There is a draft and presentation tomorrow.
• Thomas: I think we need to see what other work exists.
• A: We have an opportunity to take what ForCES did.
• Thomas: I do not know, but we need to go voer cataloging what work exists.
• B: Another is how to do per-subscribed acocunting.
• C: I build middle-boxes. Content inspection. I am very supportive. You can only count on what oyu see. There is a disconnect between how we encap and move traffic versus teh services we try to apply to it. That is a very high level concern to me, from SDN, or wherever, how we put the pieces together for a solution.
• D: I guess the reason we are here is t ocollectively explore the posibility of implementation, systems and services, and protocol machinery for IETF to create tools to address this issue. I do not think that individually we need to say if it is good or bad. Collectively we should -- where do we redirect the discussion for those 3 elements?
• Thomas: Thank you. Last couple of minutes, let me ask aloud. Answers are yes/no/no opinion
• Thomas: is this important? Yes: a lot. No: none.
• Thomas: should the IETF work towards creating a WG? Yes: slightly fewer but still a lot. No: a couple.
• Lou Berger: Clarification question. You just recast the question (you said no want WG). The question is unclear because I do not know what "towards creating a WG" means.
• Thomas: I do not want to ask create a WG because we still need to figure out what this means, scope, charter, etc.
• Thomas: How many people are willing to work on docs? <hands raise> good number.
• Thomas: Those were last closing comments -- we are done. Thanks everyone.
  
  

EOF.