=============================== Service Function Chaining (SFC) IETF 100 - Singapore Tuesday, November 14, 2017 9:30-12:00 (UTC+08:00) Meeting Minutes =============================== SFC WG chairs: Joel Halpern, Jim Guichard SFC secretary: Tal Mizrahi Chair Slides ------------ Presenter: Joel Halpern Slides: https://datatracker.ietf.org/meeting/100/materials/slides-100-sfc-sfc-wg-chairs-ietf100/ Summary: - Note well applies. - The agneda for the current session was presented. - NSH was approved for publication. - There is some work-in-progress on rechartering. Some initial thoughts may be presented today, if time permits. SFC Multi-layer OAM ------------------- Presenter: Greg Mirsky Slides: https://datatracker.ietf.org/meeting/100/materials/slides-100-sfc-sfc-multi-layer-oam/ Summary and discussion: - An update on the multi-layer OAM document was presented. - Main scope is active OAM, i.e., using test packets being injected for measurement. - SFC OAM identification is based on a dedicated Next Protocol value, and the 'O' bit in the NSH. - SFC OAM demultiplexing is another issue, based on the UDP port. - Kyle Larose: there is also an NSH Ethertype. In NSH over Ethernet the suggested method is not possible. - Greg: clarification: UDP encapsulation is inside the NSH. - Echo request/reply is used for connectivity verification. - An open question is whether we want to use these packets with timestamps to compute delay. - Kyle Larose: there is a draft that talks about ways of building the reverse path algorithmically. What about implementations that use these algorithms? - Greg: good point. There are global flags, that can be used for various purposes, including optional fields. Timestamp might be one of them. - Kyle: is that what the TLV is for? - Greg: yes. - Greg: Feedback is welome. - Kyle: you request a ‘Next Protocol’ value. Should it be a common type with IOAM? - Greg: different type. We are discussing active OAM. An alternative approach could be to implement active OAM using metadata, but that is currently not the proposal we are talking about. - Adrian Farrel: good presentation. It is good to have the options on the table. Need to throw out some of the options, and end up with one way. - Greg: that is our intention. We want one thing that we all agree about. Options are nightmare for implementers. - Greg: we would like to ask the WG chairs to consider adoption. Path Consistency in SFC OAM --------------------------- Presenter: Ting Ao Slides: https://datatracker.ietf.org/meeting/100/materials/slides-100-sfc-path-consistency-in-sfc-oam/ Summary and discussion: - COAM stands for consistency OAM. - An SFF that receives a COAM request forwards it and also responds with a COAM reply. - Joel: if an SFF is supporting multiple service functions in the chain, would it send one reply, or separate replies, corresponding to each SF? - Ting: it should send a reply for each of the SFs. - Kyle: what if there are multiple choices for SFs (load balancing). Do we represent the group as one entity, or is there a response for each member? - Greg: there is a difference between Joel's question and your question. It is a very useful option which may be worth to consider. The current proposal does not address that. - Joel: the SFF may not know how many instances are behind it. We have to be careful. - John Strassner: this assumes every SFC knows where it is going. What if we have a policy that requires two service function paths? - Joel: these are separate service function paths. - John: what if we want to identify different service paths? - Greg: it is not what we intended in this proposal. We are analyzing a single SFP. It is not necessarily a 1:1 mapping with RSP. - Joel: there is one other implication. There may be multiple SFFs from a given SF. How are you tracing the correct RSP? - Greg: that leads us to another presentation that Ting will present. We realized that there is no method of identifying RSP within SFP. We will present a proposal of how to do that. - Kent Liang: it may be good to clarify the load balancing aspect. If there are multiple instances, then which one do you respond to? There is a way of selecting, and it may be stateless or stateful. It may be good to have a section about that. - Greg: contributions are welcome. - Kyle: how is the implementation for returning the source address? How do you know if it is valid? - Ting: the source address is returned in the SFC OAM echo request message. - Greg: if we use echo request / reply, then we need to use a source TLV to return information about the address. - Kyle: are you comparing the source address against something else in the packet? - Greg: there could be a different policy. It is currently out of scope of the document. There may be other mechanism to authorize the source. - Kyle: should we reply with an explicit packet specifying that it was denied if it fails? Otherwise a misconfiguration in the control plane could look like a problem in the data plane. - Greg: logging some information will be sufficient. Explicit replies may present a security vulnerability. Return Path in SFC OAM ---------------------- Presenter: Ting Ao Slides: https://datatracker.ietf.org/meeting/100/materials/slides-100-sfc-return-path-in-sfc-oam/ Summary and discussion: - A summary of the updates in the draft was presented. - Security considerations were revised. - Joel: if the entity that generates the reply already knows who the source, then it does not need another validation. It does not add up. - Greg: it is not a scenario we thought of. If you send a reply to a different sender. - Joel: you need to rewrite the security considerations. - Greg: we will look into it. The sender of the echo may be different than the one the response is sent to. Scalability of SFC ------------------ Presenter: Ting Ao Slides: https://datatracker.ietf.org/meeting/100/materials/slides-100-sfc-scalability-of-sfc/ Summary and discussion: - The draft discusses four scenarios related to scalability: join (SF added to existing SFC), redundancy, bypass, failover. - Joel: the C1, C2 terminology is no longer part of the WG terminology. The NSH document has been approved for publication, so we will only make changes in NSH if there is a very strong reason. The issues described related to C2 – there does not seem to be anything new needed here. - Kyle: regarding the NSH extension or metadata for the flow identifier: first, we do not want to open NSH. Second,the metadata version is 32 bits long, and the other version is only 8 bits long. An 8 bit flow ID is not enough entropy for load balancing. Strongly suggest to go with solution that allows more than 8 bits. Another issue that needs to be discussed in the requirements is what it means to join/leave the forwarding plane with minimal impact. - Joel: the control plane draft is no longer a WG draft. No need to comply with it. Performance Measurement with Alternate Marking ---------------------------------------------- Presenter: Greg Mirsky Slides: https://datatracker.ietf.org/meeting/100/materials/slides-100-sfc-performance-measurement-with-alternate-marking/ Summary and discussion: - Alternate marking creates a sequence packets that are marked in the same way. This marking is used for the measurement: loss and delay. - The proposal is to use two bits from the reserved bits in the NSH for alternate marking. - Alternate marking is discussed in IPPM. Presented also methods for compact alternate marking, which minimizes the number of bits used for marking. - Alternate marking can be used for residence time measurement. NSH Encapsulation for In-situ OAM Data -------------------------------------- Presenter: Frank Brockners Slides: https://datatracker.ietf.org/meeting/100/materials/slides-100-sfc-nsh-encapsulation-for-in-situ-oam-data/ Summary and discussion: - IOAM is used to carry per-hop metadata in-band in data packets. - IOAM is being developed in the IPPM working group. - IOAM encapsulations are being presented in a few WGs, including SFC. - The ‘Next Protocol’ is used for indicating the IOAM data. - Kyle: I like this approach. My concern is that a device that does not understand the ‘Next Protocol’ should drop the packet. - Joel: SFFs are not supposed to look at the next protocol. - Kyle: yes, but in some cases some nodes may drop the packet. - Greg: what is the value of the ‘O’ bit in this approach? - Frank: will be discussed on the next slide. - Frank: our original open source implementation uses MD type 2. Another option is to use the ‘Next Protocol’, which is what the current draft proposes. - Frank: it is an open question whether we want the ‘O’ bit to be set in all IOAM traffic. - Greg: I disagree with your interpretation of the ‘O’ bit. You can use both the ‘O’ bit and the next protocol (which tells you what resides next). This is why our active OAM proposal uses the next protocol, as well as the ‘O’ bit. I would be happy to get rid of the ‘O’ bit. - Frank: I am just saying that we need guidance of what a node should do when it receives a packet with the ‘O’ bit set. - Greg: that is an implementation detail. What do you recommend regarding the ‘O’ bit? - Frank: the current document proposes to set the ‘O’ bit. - Greg: are you proposing to use MD type 2 or ‘Next Protocol’? If the latter, then it looks like active OAM. - Joel: the proposal is for IOAM to have a ‘Next Protocol’. - Greg: I can recall there were objections about this regarding active OAM. - Joel: there is an issue about what SFFs do with the ‘Next Protocol’ if they are unable to process it. We need to call it out in the document. - Frank: we originally went with the MD Type 2, but decided to go with ‘Next Protocol’. - Jim: let’s take this issue to the list. - Mickey S: regarding the ‘O’ bit – the default behavior if you do not support OAM is to drop the packet. We do not want to use the ‘O’ bit. - Joel: good point. It may be better to use a reserved bit instead. Let’s discuss on the list. - Frank: Proof Of Transit (POT) is something to be considered as a security mechanism for NSH. Should we adopt POT in SFC? - Joel: it is important for the WG to consider. - Greg: in VXLAN-GPE you do not have a choice but to use ‘Next Protocol’, right? - Frank: right, we will discuss it this week in LISP. - Greg: it may be good to understand that in some encaps there are TLVs, and in others such as VXLAN-GPE it is not possible. We want to be consistent. - Frank: there is no one solution, since some protocols have the ability to use TLVs, and others do not. MPLS Forwarding Plane for SFC ----------------------------- Presenter: Adrian Farrel Slides: https://datatracker.ietf.org/meeting/100/materials/slides-100-sfc-mpls-forwarding-plane-for-sfc/ Summary and discussion: - The draft discusses how MPLS can be used for SFC. It is being discussed in the MPLS working group. - We are looking at environments in which deployed MPLS routers can be used for creating an SFC, rather than using NSH. - Carlos Pignataro: it is important to run SFC on existing MPLS data plane. Have you considered running NSH on MPLS? - Adrian: yes, we have considered it. In this case MPLS is purely a tunneling mechanism. Still, something has to process the NSH, which will have to be implemented in software. - Carlos: you mean MPLS in SFFs, or MPLS in SFs? - Adrian: MPLS in SFFs, which are implemented by MPLS routers. - Carlos: you are neither doing swap nor pop, right? It looks like something different. - Adrian: it is very similar to how you process NSH. It is a swap operation. - Carlos: in NSH, every SF processes the NSH. In your solution, the SF does not process the MPLS. - Adrian: today, if the SF is not NSH-aware, we use an NSH proxy. - Carlos: so the SFF is also an SFC proxy? - Adrian: we will use an SFC proxy, not necessarily in the SFF. - Greg: how do you use SFC OAM over MPLS? - Adrian: we haven’t yet figured out how to do OAM in SFC, so it is early to say how it will work with MPLS. - Greg: have you thought about how to do OAM in this case? - Adrian: yes. - Joel: there is no ‘O’ bit. - Adrian: you can use a GAL label. - Andy Malis: you could have a special context label that implies there is OAM there. - Joel: as a co-chair I agree this work would not fit in the SFC WG. - Wim Henderickx: you need to define how the proxy will work in the stacking case. - Adrian: right, it needs more intelligence. Just as in NSH, we would need more complicated action here. - Zafar Ali: special label really depends on the need. We do not necessarily need that. Perhaps the work needs to be in SFC, and maybe there is no need for MPLS-specific changes. - Kent: I was reading a draft about segment routing with MPLS. How is this related to that draft? - Adrian: there are two related drafts. One is presented next in this session. Another draft is being discussed in SPRING. - Zafar: segment routing involves MPLS hardware, so it is related to the current draft. Service Chaining using Unified Source Routing --------------------------------------------- Presenter: Shaowen Ma Slides: https://datatracker.ietf.org/meeting/100/materials/slides-100-sfc-service-chaining-using-unified-source-routing/ Summary and discussion: - The draft proposes a unified approach with MPLS and NSH. - The NSH is transported over an MPLS network using segment routing. - Greg: the SFF label can be in an MPLS tunnel which is swapped. You do not have to specify a classifier. It will be an LDP-based loose source routing. Looking at this label stack it may be assumed that SFFs are neighbors, but between them you can have MPLS tunnels that are constructed based on IGP extensions for SR. - Shaowen: We are considering two alternatives. One options is to use both L2 and L3. We believe there is a local behavior. - Greg: I hope that you are using existing IGP extensions. - Shaowen: yes, we will be reusing IGP/BGP extensions. - Xiaohu Xu: I am a co-author of this draft. I understand the question was whether we could use an LSP directly instead of LDP tunnels between SFs. We could directly use MPLS routing for this. But to meet the transport independence requirement which is important in SFC, we would like to support multiple underlays: IPv4 or IPv6. - Wim: question – are you proposing a full proxy on the SFF? - Shaowen: yes. - Wim: you are not proposing for the SF to process the NSH? - Shaowen: yes, that can be done too. - Adrian: comparing this to the previous presentation, what is the role of NSH here other than metadata encoding? What happens with the other fields in the NSH? - Shaowen: that is up for discussion. We do not require every hop to process the NSH. If there is a software switch/router that is NSH aware then it can process NSH. - Adrian: I am concerned that you are using protocol fields that are not being used. You may want to replace NSH with metadata. - Shaowen: metadata is important. - Adrian: right, but you only need metadata – no need for NSH. NSH will cause confusion. - Rober Raszuk: why are we focusing on 5 labels in the data plane when we can do all the steering in the control plane? Why is this data plane centric? - Shaowen: we are also looking at the control plane. NSH Context Header Allocation: Timestamp ---------------------------------------- Presenter: Tal Mizrahi Slides: https://datatracker.ietf.org/meeting/100/materials/slides-100-sfc-nsh-context-header-allocation-timestamp/ Discussion: - Greg: I suggest to allow support for NTP format as well. PTP is and advantage for HW implementations, while NTP is more suitable for SW. Another question is why not use the alternate marking method instead of integrating a timestamp. Alternate marking does not require accurate synchronization. The Timestamp metadata puts a stronger requirement on the network because of the synchronization. - Tal: I would like to see alternate marking - it is a good method. Measuring delay is only one of the use cases for the timestamp metadata. There are other use cases which are not covered by alternate marking. Regrading the NTP format - we have already added it to the draft. - Greg: alternate marking measures loss as well. - Linda Dunbar: is this intended for adjacent nodes, or across the network? Will all the network have to be synchronized? - Tal: we are talking about an SFC domain. When you use timestamps, you assume there is some kind of a synchronization mechanism. - Linda: synchronization is very expensive. Would it be possible to support something without synchronization? - Tal: some of the use cases that are described in the draft do not require synchronization. However, we believe that if you are using a timestamp metadata, then it makes sense that your network is synchronized. SFC dynamic chaining and service indirection -------------------------------------------- Presenter: Debashish Purkayastha Slides: https://datatracker.ietf.org/meeting/100/materials/slides-100-sfc-sfc-dynamic-chaining-and-service-indirection/ Discussion: - Joel: are you multicasting these packets? - Debashish: we can have multiple instances of a producer connected to a single consumer. In that case we may use multicast. - Kyle: I read the draft, and did not quite understand it. You are using HTTP as a transport – how do you use it? Is traffic being encapsulated in HTTP? Are you using HTTP PUT? HTTP is not usually used for carrying traffic. - Debashish: we are using the URL to identify endpoints. - Kyle: maybe we do not need HTTP, but only naming using URLs. - Joel: a lot of clarification is needed here. Please take it to the list. Optimized Service Function Chaining ----------------------------------- Presenter: Artur Hecker Slides: https://datatracker.ietf.org/meeting/100/materials/slides-100-sfc-optimized-service-function-chaining/ Discussion: - Kyle: question about the SF ID. What if a packet visits multiple times in a service chain? - Artur: in principle it can work with any ID. We focused on the transport domain, which ends at the SFF. - Kyle: I am not sure I agree. - Artur: let’s discuss it offline. Rechartering Discussion ----------------------- Presenter: Joel Halpern Summary and discussion: - This is very preliminary. - There are probably too many items for the charter at this point. - Proof Of Transit (POT) is something we want to consider. - OAM is another important issue we want to address. - Security considerations will also be important – integrity and authentication. - Transport considerations, e.g., what happens when there is congestion? - Network management – we will need to define YANG models. - Control plane work, related to BESS and PCE. We are not going to define a control plane protocol. Our focus is integration and coordination with the ongoing control plane work in other places. - Interoperation with existing service chaining mechanisms that precede NSH. - Metadata, including MD Type 2 and MD Type 1. - Collaborate with other working groups that propose work related to SFC. - Hierarchical SFC solutions. - Feedback from operators and actual deployments. - Uma Chunduri: segment routing has to be deployed with NSH. We may need an explicit charter item for SFC with segment routing. - Kent: operational considerations includes some of the drafts that were discussed in the past? - Joel: that draft does not seem to be related. Need separate item for that. - Xiaohu Xu: when defining new encap such as NSH, there are considerations that need to be considered about how to transport this new encap over MPLS. - Joel: clearly we do not take the work of the MPLS, but if there are MPLS-related issues we should identify them. - Wim: interoperability between SFFs is not possible today, because things are not clearly defined enough. It would be nice to have that. Specifically, focusing on how NSH works over Geneve and VXLAN-GPE, from interop perspective. - Artur: I agree. We may need BCP about interoperability. - Frank: how do you decide on priorities between items on the charter items? - Joel: Not sure we have enough people and enough time to work on all items. Good question. - Linda: what kind of OAM are we talking about? - Joel: we are talking about SFC OAM. Various proposals can be considered, and it is for the working group to consider. The charter only specifies the problem, not the solution. - Alia: the question is what do you need to get the stuff deployed. That is what we need in the charter, so that we have people working rapidly to get things done. NSH is done now. You can do the work that you care about, but it requires to put the time and energy to review the documents and get things done. - Kent: regarding the MD Type 2 metadata. That is a key item, since SF have to interoperate. - Frank: would it make sense to have an interim about the rechartering? - Joel: I would like to see discussion on the mailing list, and then we decide. - Alia: we need the charter to be done before the next IETF meeting. - Joel: I hope we can do it on the mailing list. Adjourned at 11:56