Service Function Chaining (SFC) Working Group Meeting IETF 98, Chicago Tuesday, 16:40-18:40 WG Chairs: Jim Guichard, Joel Halpern. Minutes by Ignas Bagdonas and Tal Mizrahi. Chair slides ============ - Note well presented by Joel. - Chair slides presented by Joel. - Agenda bashing: no comments. SFC Use Cases FOG RAN ====================== Presented by Carlos J. Bernardos Summary: - Radio Access Networks (RAN) are becoming virtualized. - Current draft focuses on applying SFC to Fog RAN environment. Joel: If you use SFC to implement this scheme, you need to meet the latency budget and topology. Would that focus on the requirement for the control plane, or on how to apply SFC architecture onto these requirements? Carlos: Both deployment and protocol requirements. Uri Elzur: Could you share some information on how Fog RAN could use a more complete solution than just the data plane. Also what are your thoughts on interoperability? Carlos: no clear picture yet about solution. Will work on solution later on. Currently focusing on requirements. Uri: What requirements do you have for information exchange netween service functions? Carlos: RAN signal quality, load information may affect the operation considerations. Uri: It would be nice to get that information. NSH Context Allocation: Timestamp ============================ Presented by Tal Mizrahi Joel: Encouraging to ask questions. There cannot be any more variations of MD type 1 as it is a fixed encoding and does not fit the timestamp in. Tal: You can mix and match timestamp with other allocations. Joel: The same applies to security draft too. Greg Mirsky: Can you recapture the purpose of the timestamping? Are you trying to measure residence time? Tal: I will try to answer later in my presentation in 10 minutes. Greg: I would recommend to support NTP timestamp format too. If you are taking the clock of your hardware that is running IEEE 1588, you are synchronizing the clock on the forwarding engines and not necessary on the compute part for the control plane. If you use NTP this would help inconvergence, although that is trivial. Greg: Second issue is the consistency of taking the timestamps. If you are taking timestamps in SW and outside of HW, you may encounter the inconsistent latency, and the measurements will not be correct. The latency of control plane packet processing is nondeterministic and it is hard therefore to say what you are measurement. It is a stong requirement to take timestamp of first bit sent and last bit received in HW. Thus you can calculate the delay and variation of the path consustently and not related to SW processinf. Gewtting correct data is reallyhard. Tal: If I understand correctly you are talking about the method of taking the timestamp. Greg: yes. Greg: Another comment on context switching. 1588 has transparenbt clock for residence time measurement that allows for accounti ng of propagartion of PTP message propagation, and using this you can avoid timestampi ng each packet. Tal: What you are saying is that we can add additional field? Greg: No. You can run measurement of the residence time on each node and you will know the time for switching the context and that will indicate the delay needed to treat the packet flow. Joel: Is your assumption that this is used for packets carrying no other metadata? Tal: Yes, type 1. Although we are open for discussion. The main point of this draft is to have timestamps. Sumandra Majee: Would it be good to have timestamp type field? Why existing service delay measurement approaches are not applicable? There are alternative methods to solve this. Tal: I have addressed that in KPI stamping slide. Different methods are not necessarily implemented by all vendors. Sumandra: If I try to debug which particular function is causing the delay, there is no requirement to have very accurate timestamps, even TCP timespamp would be sufficient. How operators will integrate this into the existing analytics tools, and how they will use this new mechasnism? Tal: You can use other OAM mechanisms too. Sumandra: If it is not an absolute requirement, I would prefer not to have it on my network. Tal: You should try to convince the WG that type 2 is mandatory. Greg: You can use SF proxy for that. Stewart Bryant: I got the impression that these are special packets and not live packets. You should be timing the time taken to traverse the function. Tal: This is on live data. The actual measurement does not have to be on all the data. Metadata is there for all data packets. Kyle Larose: Have you considered what it means for reclassification or in a proxy environment, will you need to redo the timestamping? Tal: We will need to consider whether if we reclassify we will keep the old timestamp. NSH Context Allocation: Broadband ================================= Presented by Praveen Muley Presentation: Joel: We have discussed carrying MD 1 and 2 in multiple contexts so this seems sensible. Are you trying to allocate a class code for 3 GPP, and then use that class? Praveen: Yes. Adrian Farrel: Once we allocate the class code in 3GPP, isn't everythig else is not in scope of the IETF? Joel: Yes. They will ask for the definition of the types. Adrian: Also for documentation. Having RFC that talks on how to allocate the class seems to be needed. Experience designing minimal independent control plane talk =========================================================== Presented by Sumandra Majee Summary: This presentation describes experience with a minimal SFC controller. Greg: You have a hash - what specific information of hash are you looking at? Number of interfaces? Sumandra: It depends on capabilities of the device. If it can do address and port hashing only. Greg: Do multiple capabilities mean which hashing algorithms to use? If you have multiple available, you need to spelect a specific one for use. Sumandra: Yes, it is in a minimum configuration. Kyle/Sandvine: Found this interesting. I have worked on Sandvine's solution that has skip functionality. Why do you say that you should not worry about the classification rules? Sumandra: In mobile use case, the rules are coming from PCRF. For building the service chain, the rule is required for flow to path mapping. We need a consistent API for programming the devices in the middle. Kyle: Did you find use for NSH metadata? Sumandra: Yes. Side benefits of NSH: use NSH metadata instead of the GXM parts. Kyle: Would that be in scope? Sumandra: Yes. We could solve that with some scripting language. Pedro Martinez-Julia: The skip mechanism is not necessary from the beginning. You are not building one chain for a long term, you are building chains dynamically. Sumandra: Yes, skip is not required, it is good to have. My feedback from operators that they are not that dynamic. Looking at the number of the API calls required for setting up the path - that is a very large number. If you need 10 calls for one element, and you have n elements, it may be be too large for dynamic chain building. If some element is overloaded it may be simpler to skip it than to rebuild an new chain instead. Pedro: The hgher layer manager can decidse that. Instead of putting in all orchestration logic into path creation, we can decide that except of first and last functions, functions in the middle can be filtered. Sumandar: My vendor answer is yes, sure, go ahead and fo whatever you want. The second answer - it is not bnecessary that dynamic, and top redirect a flow is simpler. Pedro: The complexity is coming from inside the box. You need to reduce the complexity of the implementation, and this proposal moves complexity from the management plane into control plane. Kyle: If you video optimizer crashes, you spend 10 seconds to reprogram the flows, or you drop everything and redo again? If you redirect the traffic dynamically? Joel: what I hear from different people - we need more desription of the problem space. Jeff G: It would be good to have a draft on that. Joel: The WG will decide whether it has interest when they see a draft. Uri: What does this WG want to do to make NSH and SFC in the industry? What tools do we have to enable broad industry deployment? We have invested in data plane, PCRF is another interesting optiom. Maybe we could do something as a liaison, together with opensource consortiums on what you cann the minimal controller, an implementation that shows the path. Then we potentially could take off, now we are the plumbers building something. Sumandra: Not certain whether that will take off. Adrian F: This is useful for discussion. I am not certain how much of that will end as an RFC, draft would be of use for this. The title of this slide is very different - minimum controller vs minimum control. The control and magamement plane pieces in a very simple network in a centralized way makes sense. But in a larger network out BGP document might be the right solution. Please take a look at it and provide feedback. Soumandra: That draft tries to address similar use cases in rather different way. Joel: There is also a PCE draft that tries to address this. Open-mic discussion =================== Topics: - Progression of use case documents - Progression of control plane requirements document - others (?) Joel: Other topic that are open and matter to you to discuss? Kyle: Need to close the TTL discussion. Joel: Would you like to use the TTL mechanism provided? Kyle: yes. Joel: What you said seems to be consistent with my observation of the WG rough consensus. Tal: Another topic that was discussed in the interim was making MD type 2 with length of zero mandartory, and it seemed that there was consensus at that time. Can we bring that into the specification? Joel: Seems to make sense. Will need to follow up on that. Joel: We had discussion on C bit going away. That has implications on OAM. As far as I know we are looking into the current text as the agreed that has the C bit. Does someone want to bring that foirward? Jim G: Please read the interim minutes, they have many topics covered. We captured 20-30 action items on various topics. Me and Joel we were focusing on at least the NSH action items. TTL was one of the last items on that list. Editors of the NSH document were busy lkeeping up with those actions. Use the mailing list for discussion, lets try to tie those loose ends. We need hel from the community to do that. We need to be surer that we are pushing the working group in the right direction. I do not want to go away from here and have the same conversation in Pgaru egain. There needs to be a draft about the minimum requirements that need to be done. We have many discussions on the control plane document and it semes that it is not clear what nwe need to do. JimG: One of the things that was a feedback from the interim was on the metadata. We felt that we should adopt some of the type 1 document and get more eyes on them. If there is no objection then we will start the adoption. Second was that we wanted to move the type 2 documents foroward. We came to conclusion that it was useful to have a document that lists as the of tlvs that can be described in a short manner without a specific detailed explanation in separate documents. We looked to get a new editor for TLV document, Sumandra agreed to do that, that is another document that is in line for adoption. Joel: The goal is not to have the single document that control the assignment of the ciode points, it can be done in other odcuments too. If we have type 1 document, we can define in that document a type 2 codepoint that is described there. We are also looking how to move the OAM document forward. Now that NVO3 is going through the overlay OAM work, we are looking into how to alight with them. We are not going to say that we must own because we own it. We are collaborating with other people ta make things work for the IETF. Do we need a separate security docuemnt? We did not hear much support for the document. Please speak on the list. JimG: Any more burning issues that you have? Carlos Pignataro: awareness of the work of in-situ OAM (IOAM). It was presented in various WG during last two IETFs, there is running code, targetting many applications relevant to many groups. That work was brought to IPPM, we are targeting the adoption of data structures document, there seems to be good support for that. The transport work may happen in different WGs, we may come back to SFC asking for a code point. One of the drafts, Proof of Transit (POT), talks about proof of transit in the context of service chaining. It might be too early at this time, but when it matures a bit more, we might come asking for adoption. We want feedback on that. In a mid term we may rerquest for SFC to be a home for POT. Joel: End of the meeting. 01:55 Closing (WG-chairs)