SFC BOF, IETF-88 Vancouver Thursday, November 6, 2013 BOF-chairs: Jim Guichard (jguichar@cisco.com), Thomas Narten (narten@us.ibm.com) ----------- Presentation: Introduction -------------------------- (see meeting materials) http://www.ietf.org/proceedings/88/slides/slides-88-sfc-2.ppt BoF chairs: - provided an overview of the agenda, note-well, distributed blue sheets, etc - explained this is a working group forming BOF. Key elements to address include: - consensus that there is work to be done and that work is within scope of the IETF - clear identification of and focus around work topics - critical mass committed to do work - rough consensus on a draft charter BoF chairs: - update from Berlin BOF - One-hour non-WG forming BoF, 250+ people in the room, demonstrated strong support to do work. - Since then good discussions on the SFC mailing list and progression of existing drafts - problem statement, use cases. - several new drafts submitted since IETF 87 - Proposed charter - few iterations completed and rough consensus reached on the SFC mailing list. Presentation: Problem Statement (Navindra Yadav) ------------------------------------------------ (see meeting materials) http://www.ietf.org/proceedings/88/slides/slides-88-sfc-1.pptx Navindra Yadav provided an overview of the problem statement draft - http://datatracker.ietf.org/doc/draft-quinn-nsc-problem-statement - basic issues with current designs - topological dependencies - configuration complexity - vlan stitching, vrf stitching etc. - hop-by-hop forwarding, PBR - operations nightmare - impossible to build large scale - not flexible - tight coupling of network and services limits HA - vendor neutral implementation of policies for - mobile vs. wireline separation - address capacity needs with elastic compute and service instances - mix&match physical and virtualized service functions based on needs - rigid service ordering - per flow service ordering is hard to achieve, not scaleable - other issues - multi-vendor interoperability - support policies that require sharing service context, service metadata Questions/comments: - No questions or objections from the room. Problem statement has been discussed at length on the SFC mailing list. Presentation: SFC use cases (Hongyu Li) --------------------------------------- (see meeting materials) http://www.ietf.org/proceedings/88/slides/slides-88-sfc-4.pdf Hongyu Li provided an overview of high level use cases - http://datatracker.ietf.org/doc/draft-liu-service-chaining-use-cases - two use cases - (S)GiLAN and NFV - (S)GiLAN - network services are implemented over the LAN - right-side from P-GW - a large number of L4-L7 services can be implemented - the idea is to provide service-specific traffic steering - different from normal forwarding/routing - traffic steered via service function chain based on service characteristics and policy - today's approach - hard-wired configurations, policy based routing - manual configuration - tight coupling between the service function chain and the LAN topology - what's required - auto service provisioning - simple and instantaneous service function chain provisioning - expandability - support for virtualized service functions and elasticity - NFV - NFV requires applying virtualized network functions in pre-defined sequence - to support VM mobility SFC must be decoupled from the underlay network topology - see ETSI NFV for detailed breakdown of requirements Questions/comments: Paul Quinn : some questions about mobility use cases. What granularity for classification criteria is used to select the appropriate chain because certainly you are dealing with a large number of users/subscribers? have you identified a need to pass information between services in GI-LAN use case? Hongyu Li : No specific example for the second question but yes it is necessary. For the first question it depends on the operators requirements but it is absolutely not per-subscriber, its per-service (e.g. per destination, or per port). Paul Quinn : as you expand on this use case do you plan to illustrate certain types of classification or criteria that will be used for the selection?. Hongyu Li : yes Paul Quinn : maybe we should talk about this on the mailing list - e.g. what type of granularity is required. Sri Gundavelli : trying to understand the difference between your first use case and the second one. I understand the GI-LAN service requirement and the path chain but the next use case network function virtualization, what is the difference between the two? can you clarify? Hongyu Li : the first one is a real case that has been deployed - the service functions may be physical boxes as well as virtualized ones. The second one is the pure virtual world where all of the service functions are virtualized in the data center and you have to chain them together to form a service - these might be different requirements for the technology you want to use Sri Gundavelli : but what difference does it make - its just a path right - whether the functions are virtualized or real - anyway its a minor comment Parviz Yegani : two comments. I agree with Srini - if you go back to the NFV diagram. You can have a mix of physical and virtual functions so this framework is not limited to a few virtualized functions. That should be within scope. Hongyu Li : This is correct, both types of service functions are expected to be in scope. Parviz Yegani : Secondly, I can see an issue with the term "chain" or "chaining" - i think the scope of the work here should be more like service function graph vs. service function chaining. That would really broaden the scope and we can attack a more extensive problem. Jim Guichard : I think that will be addressed in the architecture discussion because there have been various discussions on the mailing list about whether this is just about a simple linear type steering between service functions - there are many use cases that show this is more of a graph topology and thats what i think the architecture discussion will get into to some degree. And I think the other point here to make is that what we have tried to show is just a couple of use cases but there are lots of other uses cases and we showed some of those in Berlin - the GI-LAN case was one of them and that might have specific requirements that you might not see in the NFV case for example. The main point is that these use cases should be what drives the problem statement and therefore drives the architecture. Deng Hui : two clarifications. The first one is the Gi-LAN case - where is the classifier? Hongyu Li : actually this is a use case and we don't propose any solution but the classifier is either in the P-GW or a standalone device - you can put it anywhere but if you want to do the chain you need a classifier someplace Jim Guichard : the classifier is a component - how you would implement that is implementation specific Deng Hui : what i have a concern about is the location of this classifier is in other standards scope for example 3gpp - do we have a requirement from them that we should do something for that? also does NFV have gap analysis about the work the IETF should do? is there any ongoing work or are they ready to do that? Hongyu Li : NFV is so far working on the requirements and use cases, they are not working on the technical specifications and the gap analysis is not finished yet. Gap analysis was only just started. Deng Hui : if gap analysis is not finished how can we understand what is the gap? Thomas Narten : i don't think that NFV has provided the gap analysis yet - thats like 6 months down the road - they are not coming here asking us for solutions - at this point we are trying to demonstrate there is a need for doing service function chaining at a high level and we will get requirements on the details as we work through the problem statement and from other inputs such as NFV. Also, nobody is recommending that the working group works on the classifier - there is no work item and nobody is talking about specific work on the classifier. Deng Hui : I don't think the gap analysis is the solution plan, it's more like what's the today's world and what's needed. What I've heard is that there an ongoing analysis work on the NFV side, but if we don't care about the analysis work in NFV, that's also fine. Thomas Narten : we definitely care, and once this gap analysis is available we will presumable look at it. But before it's available it's premature to speculate where it's going to go and what we should be doing in this space. Let me ask you a question - the first question you ask about the classifier, were you asking or suggesting the work be done about the classifier ? Deng Hui : if we do something with classifier that is covered by other standard body, then we need to do more discussion than just in IETF. Thomas Narten : let's be clear, at least from my perspective, this proposed WG is not going to do any work on the classifier, it is not a work item, and nobody is talking about anything specifically related work to classifier. They are out there, and if work is to be done, nobody has surfaced this as far as I can tell. Deng Hui : but I see this as a function listed on the slides. Jim Guichard : the classifier is a component of the architecture - in other words you have to be able to direct traffic on to a service chain somehow but we are not here to build traffic classifiers. Jim Guichard : another point to make is that NFV is just one use case and there are other use cases to be worked on right now. Parviz Yegani : there is a misnomer here - traffic classifier is not in the context of classifying the flows - it should be a policy system and that policy system has to provide some information for the packet that enters the network at the very first service node - based on that policy that is already in place whether static or dynamic then you can separate the flow - so this is not IP flow classification, this is different. Jim Guichard : yes, agreed. Lucy Yong : i have a clarification - earlier on your talk about the granularity - is that a granularity per-flow or per-service chain - you are saying its not per-subscriber its per-service? Is it possible you to have multiple services using the same service chain ? Hongyu Li : right. the same service function chain means the same policy is used. Why do you need to distinguish further ? Lucy Yong : if I'm a mobile services operator I may have several services, but will these service use the same service function chain or different ones ? Honyu Li : depends on the policy. Florin Balus : to the use case it would be very useful if you can complete the workflows - start from the beginning - so basically specify who creates and who designs the service chain, who instantiates the service chain, and who has the control on changing how the functions are being chained - this is very important for the overall analysis of the solution. Jim Guichard : agreed. Paul Quinn : i believe in Berlin we had a representative from ETSI request that we look at the use case from NFV as part of our work. Jim Guichard : yes, Diego, are you in the room and would you like to say any words about that? it would be nice if you could just clarifying for people in the room the work in NFV and how you see the liaison between ETSI and IETF moving forward. Diego Lopez : in NFV we are working on the "gap analysis" but it's not necessarily the "gap analysis" in the context of the discussion here. We are identifying the relevant SDOs, to achieve what we think should become the NFV solution. Doing it right now, we present our first results in mid February, one of the parties we're talking to that's on the top of the list is IETF. Note one important thing about SFC and NFV. Here we're talking about how to use SFC inside NFV, but in fact we're talking about two different layers. To build the final service composing NFVs, it means very likely to provide the infrastructure network that's connecting them. In the 2nd case, my view, and it's not NFV view necessarily, will concentrate on the aspects of the data plane with a lightweight metadata tagging for building infrastructure network. In the case of building the service, that's likely to involve building complex patterns, in where policy function ( or the traffic classifier ) will be the key network function to be virtualized. Or to define what someone called "the gateway" between the physical and the virtualized network. Jim Guichard : right now we have a single use case draft. We don't want to build a huge document, but what we would like to do in the problem statement is have use cases that give a high-level taste of what we're talking about, and if there are specific more detailed use cases such as for mobility, broadband or VPN, then have individual separate documents going into more detail of the specific use cases. Thomas Narten : the point of the use cases is actually the reality check - want to make sure that what we're doing makes sense in the real world. Make sure we have enough of the clearly defined use cases. But at some point we would need to establish that any new incoming use cases and applications are already covered by existing definitions. Parviz Yegani : remember in early year 2000 from the liaison channel with 3GPP, bringing requirements every week from 3GPP, trying to co-develop extensions or new protocols with IETF. The same happened, operators drove this and identified number of use cases. Maybe Diego can clarify, through the liaison that's already established, that ( use case ) information should be already passed to IETF. There is list of 10 different use cases, and are you saying that you pick the top 2..3 use cases ? Jim Guichard : No, what we're saying is that we don't want a never-ending use case draft. Instead to have something representative that people can read to understand what is to be achieved here. If there is a specific use case to be dived in, with more detailed requirements are not covered in the basic one, then it's okay to have a separate document on that. But don't want to get into having a million of documents. Parviz Yegani : use cases already exist in other places and we can just select some of them. Strongly recommends we use the input from ETSI. Thomas Narten : just to clarify, were talking about the liaison - has this information been already provided to IETF? Steven Wright : I chair the infrastructure group in ETSI - http://www.etsi.org/nfv - 5 documents available online - one of them is the ISG use case document. Jim Guichard : yes, that's what I've been referring to. Thomas Narten : one of the action items for this group is to make sure that we read this document and pull out any requirements that need to be addressed. Presentation: SFC architecture (Ron Parker & Paul Quinn) -------------------------------------------------------- (see meeting materials) www.ietf.org/proceedings/88/slides/slides-88-sfc-0.pptx Ron Parker provided an overview of the SFC architecture drafts. - http://datatracker.ietf.org/doc/draft-boucadair-sfc-framework - http://datatracker.ietf.org/doc/draft-quinn-sfc-arch - http://datatracker.ietf.org/doc/draft-jiang-sfc-arch - http://datatracker.ietf.org/doc/draft-beliveau-sfc-architecture - background - service functions used everywhere - every type of network, deployment - number of methods used today to deploy composite services - infinite number of ways - sometimes a chain, sometimes a graph - current approaches are inadequate - they're inflexible, expensive, difficult to diagnose/operate, no high availability - SFC is a new forwarding paradigm for sequencing service functions - should define set of tools to address the exemplar use cases - should support logical service entities - sharing information, metadata between appliances - passing the policy tag between the service functions - multi-vendor interoperability is the most important - drafts alignment - four aligned drafts - working together to have one common architecture draft - core architecture principles - Single administrative domain - Multiple administrative domains for future study - Multi-vendor interoperability - Network transport independence - separate logical classification and service functions - Logical identification of service functions - Sharing of metadata/context between nodes - simplified architecture - tcp from one subs vs. tcp from another subs may classify into distinct chains based on policy - optional reclassification by service function - SFC components - service function - service classifier - overlay service topology - control/policy plane - shared context Questions/comments: (?) : can you tell us what is the difference between network function virtualization and service function virtualization? Ron Parker - this was not service function virtualization, this was service function chaining (?) : is service function virtualization within the scope of service function chaining or is it out of scope? Ron Parker : service function chaining in my view is equally applicable to virtualized service functions or non-virtualized service functions. I don't think that chaining should assume one or the other. I think NFV is a use case that justifies this particular capability in one sense but this capability should be agnostic to the embodiment of the service function. (?) : in that case have you done any survey of the literature in the standards organizations in terms of stitching the service function irrespective of whether they are virtualized or not? Ron Parker - have I personally? no Thomas Narten : the relevant question is whether there is work done elsewhere that we should know about and thats certainly a valid question. Parviz Yevgani : i don't know if in the latest draft you have included a definition for a network service - network service from the end-to-end perspective is missing from the slides. What this means is that when a packet enters the first node and exits the last node they are going to realize something called a network service so we need to add that to the architectural framework. Paul Quinn : it is purposely omitted from the draft to focus the architecture on these elements - the external connectivity is not really germain to the chaining architecture because that external connectivity is going to vary and whether that is truly a service in the service provider sense is open to debate. Ron Parker : I think in one sense a service function chain and a network service are synonymous in that the end-to-end treatment of the packet by the collection of service functions is a service. Its a composite service. Thomas Narten : Let me add - one of my observations here is that we have different organizations doing work in the same space and we have a terminology problem. Some of which is : two different terms mean the same thing, or two different terms mean almost the same thing. We will have to sort it out, and the problem statement / architecture is going to be very clear on terminology, so that we don't have this confusion going forward. Parviz Yevgani : the terminology whether its network service or pineapple i don't care. What this means is that the stitching of those service functions from an end-to-end perspective - we need to give it a name and the architecture that is eventually going to be in place is to deliver that service. Strongly disagrees that this should be omitted from the architecture. Ron Parker : I think we didn't include how traffic enters this part of the network and leaves this part of the network so entry and exit into/from the chain is not something we directly addressed in the architecture. If i understood you we are saying that the graph that is followed is actually the service that is being realized and I agree. Thomas Narten : we had discussions on the list about this and the term "composite service" - we need to come up with a term for this so that we can all use it consistently. Linda Dunbar : question regarding s4 graph - specifically between the service functions SF1, SF2 and SF4, do you actually maintain a TCP session among them to keep them connected ? Pls clarify. Ron Parker : no. We have described this as a different forwarding paradigm and i can say its a connectionless forwarding paradigm. Linda Dunbar : Okay, no TCP sessions connecting SFx nodes. Ron Parker : Correct. And we haven't described the connectivity paradigm here, but it's connectionless. Linda Dunbar : Okay, so when a packet goes from SF1 to SF4, will we have an IP address of SF4 there as a destination ? Paul Quinn : the generic term used in the architecture is network locator; whether its IPv4, IPv6, MAC, does not matter. We use a network locator and establish an overlay between two points with different network locators. Ron Parker : there is a level of abstraction there - when you identify the service function you're not nailing it in space. You identify the service function and you separately locate where it is. Linda Dunbar : okay. Jim Guichard : the reason for this is that there could be multiple instances of the same service function located throughout the network. Linda Dunbar : Okay, you clarified this part, thank you. Another question - do service functions discover each other ? Ron Parker : I think there are two questions here. Discovery is an interesting question, and I think the WG that's being formed will take that up. And I think the discovery is one way to mitigate the amount of provisioning that's necessary. But then it may not be absolutely necessary, it may be nice to have. In terms of steering, that is how does the traffic get from one service function to the other, that's the underlay. If we consider the chain of service or graph of services as the overlay, then how it gets from one to the next, once you apply the locator ( MAC address, IP address ), then it's a job for the underlay layer. Linda Dunbar : that's when you assume there is only one port on the service function, but when you have multiple ports, how do you decide whether to use port number 1, or 2, ... Ron Parker : there are multiple implementations for that. One such implementation can use L3 routing semantics. L3 routing is very capable differentiating between the multiple equal cost or unequal cost paths between two entities. Nabil Bitar : some questions to the scope and some to what was said. In this architecture I see the control plane, I see classifier. 1st question : Is the control plane part of the work that's going to be done here ? 2nd question : are the interfaces along the service path also defined here ? The other thing is the service topology - looking at this graph on s4, it's a service path applied to the flow. So it's not really a service topology. For me service topology is where the service nodes live. We really need to distinct between the two. Ron Parker : taking the 2nd question - we noted there is a difference between service function chain and service function path. Service function chain is an abstract set of services that shall be followed for some flow, probably not a micro-flow but macro-flow. Service function path is realization of instances of these services. If we have a chain A>B>C, there could be four or five instances of each of those. And specific instances chosen represent the path. Nabil Bitar : looking at the service classifier on the slide example, I classify the flow and then I put it on service path. So really the edges of the graph are not really the edges of the path that this specific flow is going to take. That's why it's worthwhile to distinguish between the two. Ron Parker : definitely some work here to do that mapping of chains to paths. Nabil Bitar : another thing to explore is the value to carry information in the packet, that can imply in-band what path within the service graph specific flow should take. There could be benefits to define the policies for hop-by-hop or segment-by-segment. Telling the packet that you can get to that node based on the conditions that happen along the way it can take another edge, or multiple edges. Not sure how to represent that, but would like the WG to think about it. Ron Parker : all good point. Jim Guichard : We can take up this discussion on the mailing list. These are all valid points and i do not think there is any implication that the architecture is set in stone. Eric Lunberg : what are the building blocks that make the datagrams travel through this graph. You said that there is a locator that effectively makes the datagrams travel along the black arrows. Ron Parker : if you interpret the black arrows as the chain, where each of those SF1, SF2, SF4, represent multiple instantiated services, of if you interpret that as a path taken over a particular instance of each. Eric Lunberg : and that may imply depending on the locator, it may imply the encapsulation. Ron Parker : very likely imply encapsulation, may imply load-balancing. Eric Lunberg : but in terms of traversing SF1, or instance of SF1, you also need to have some way to represent, name the different attachment points between SF1 and the black arrows e.g. SF2. Thomas Narten : I think I know what question is - we will talk about it more during the charter discussion that is about the encapsulation. There is an assumption here - when packet arrives at SF1 there is an identifier of some sort that identifies what service chain the packet belongs to, SF1 does what it's supposed to do, and then it know what service chain it is, what position it is in the chain, and it knows where SF2 and how to get there i.e. by tunneling the packet. Eric Lunberg : but i think there are two pieces to encapsulation. There is a locator, and there is service context. Presumably the encapsulation has both of them. Thomas Narten / Ron Parker : yes. Bob Briscoe : concerned that things inside the service functions, must be constrained to something that the stuff outside, the external functions like control policy and service classifier can understand. And then we can have code that's written with logic inside it say an intrusion detection system, that says when I detect this attack, I need to do something with it, and decide to steer traffic themselves. And here we're saying that somehow we have an "all-knowing god" that understands all that. Paul Quinn : there is no "all-knowing god" - will clarify this in the updated version. There is a clear separation between the service data plane and policy plane. Next version will clearly articulate the decoupling between the encapsulation, the transport and the service function itself, so there won't be a conflict. Bob Briscoe : but you can't have both. The service classifier either will be able to set up the service chain in advance, or the functions themselves will be able to determine where to steer traffic. It's unclear how you're planning to do that. Ron Parker : We stated that additional classification function is possible and supported in each service function, collocated with this service function. So if you have a chain with classifier and service functions that do not classify, so then it's really is a simple chain. As soon as you introduce a re-classification in any service functions along the chain, then it becomes a proper graph. And classification is itself a policy driven matter. And I don't think in this WG we are going to specify what is the nature of this policy. Bob Briscoe : I have been thinking about the security of this system, being able to validate that's it's doing what you expect. It is also captured in the liaison with ETSI group. Only God will know what should happen when you combine the state of all those functions i.e. you never know where the packet is going to come out unless you understand the union of all the code and all the functions. Thomas Narten : good discussion but we need to move on as we still need to cover the charter and the open discussion. Annoop Ghanwani : Are you going to be dealing with the difference between transparent and non-transparent devices. Paul Quinn : both are valid and we must not exclude either in the architecture. Dino Faranacci : does the architecture specify loop avoidance at all, if not why not, and if it does, do you want to be able to support service nodes supporting multiple types of the header ? Ron Parker : loop avoidance is covered in some of the drafts, totally valid point. Regarding multiple headers, so is it the same logical instances, or is multiple logical functions dealing with different headers ? Dino Faranacci : how do you handle multiple re-circulations, like at a firewall that wants two bites? I'm thinking about a FW that you want to operate on the outer header and the inner header, so recirculating. Ron Parker : several ways - e.g. two logical functions. Dino Faranacci : do you want to support multipoint ? Ron Parker : i will defer. Steven Wright : can you give examples of things that wouldn't qualify as a service function? Ron Parker : difficult question - do you have any in mind? Steven Wright : struggling to apply this to an existing service. Something like DNS? Ron Parker : the way we define the service function here is some sort of a black box, packets go in, something happens to them, packets come out. For DNS, you want to query the DNS, that's completely different type of service, a harvest model. That's not traffic flowing thru a service that does something to it, it's an end-point service. Thomas Narten : distinguishes between a mid-box and an end-service. Charter: -------- (see meeting material) http://datatracker.ietf.org/wg/sfc/charter/ BOF chairs: - provided an overview of the charter and outlined deliverables - posed the question whether there is support to form a WG based on the proposed charter, modulo some word smithing. Questions/comments: Lucy Yong : what's the difference between encapsulation and protocol. BOF chairs : its an encapsulation but just word smithing - will correct the text. Nabil Bitar : you are talking about the header only and not the full encapsulation stack? BOF chairs : yes. Nabil Bitar : what is the connection between control and management plane? BOF chairs : this is a work item. Nabil Bitar : 2015? Afraid we'll lose energy, interest and be late to market. BOF chairs : we can be flexible and pragmatic. We can deliver before a milestone. Eric Lunberg : encapsulation and locator question - need more specific wording. Think about an information model instead of picking a favorite transport. Brings out OAM/Operations ... leverage what's already out there. BOF chairs : we don't want to start from scratch. (?) : is a fully virtualized network within scope of the solution? overlay? BOF chairs : yes. Parviz Yegani : is virtual network function in scope. BOF-chairs : yes. Parviz Yegani : Then is interface between chaining and orchestration in scope? Thomas Narten : this has to be clarified in work group within the next 4-6 months. Parviz Yegani : what about inter-domain - infrastructure as a service? BOF chairs : its a single administrative domain - single-domain first. Yuanlong Jiang : configuring service functions out of scope? BOF chairs : Yes. Paul Quinn : echoes comments about timing - we should derive our requirements from implementations. Lucy Yong : confused by control plane wording confuses her. BOF chairs : lets have this discussion on list. Tim Chansick : asks the intra-inter question. Thinks this needs to be clarified. Thomas Narten : you start with intra but you don't tackle inter right off the bat. (?) : wants to put another item on the charter to include guidance on the classifier. Thomas Narten : take it to the list and propose something specific for text in the charter. (?) : how is graph generated. If it comes to the management. The work in ETSI NFV MANO WG may be helpful! Co-chair of the MANO WG volunteers. Ina Minei : a lot of the disagreement and confusion comes from terminology. We need a re-classification. Chain is the wrong word. You start with a graph and traverse a chain. Steven Wright : clarification on encapsulation requirements. Will we reuse something existing or is the assumption we need a new encapsulation? Thomas Narten : assumption is we will need a new encapsulation but you don't have to use it and therefore we will do something new. Steven Wright : what happens if the ETSI reps come back with a different definition of a service graph. BOF chairs : we will handle that if it happens. (?) : What part of NFV ETSI is in scope here. BOF chairs : wrap up Q&A To the vote: is there support to form a WG with the charter as proposed? lots of hands. those that are opposed to forming a working group? Only one or two opposed. Adrian Farrel : would those opposed to forming a working group drop him or the mailing list an email explaining why they are opposed that would be helpful. Adrian Farrel : please raise hand if you would be willing to review documents in such a WG - lots of hands Adrian Farrel : please raise hand if you would be willing to write drafts if we form such a WG - lots of hands. Adrian Farrel : does anyone have a strong opinion that this working group should be formed in a specific IETF area? Joel Halpern : the work as described seems to fall into either internet or routing - declaring it to be apps or something i do not want to see happen