SFC Working Group Meeting July 17th, 2017, 15:50-17:20 ============================ WG Chairs: Joel Halpern, Jim Guichard Note takers: Ignas Bagdonas, Tal Mizrahi Chair slides ------------ Presenter: Joel Halpern Slides: https://www.ietf.org/proceedings/99/slides/slides-99-sfc-sfc-wg-chairs-00.pdf * Joel presented the note well. * Tal Mizrahi is officially SFC WG secretary now. * Joel presented the agenda, agenda bashing. No comments. SFC OAM Framework ----------------- Presenter: Carlos Pignataro No Slides presented Draft: https://tools.ietf.org/html/draft-ietf-sfc-oam-framework-02 Summary: * Background: we want to have a single place that defines what we want to do in OAM before defining solutions. That was the purpose of this document. * The document discusses the OAM requirements and functions. It does not define protocols. * The document includes a mapping OAM functions to OAM protocols. Discussion: * Greg Mirsky: questions now or at the end? * Joel: questions that are relevant document can be asked now. * Greg: the direction of the document is a bit different than the original scope. The document describes solutions. The gap analysis and toolset should be removed. * Carlos: The additional section is intended as an inventory of existing capabilities. It was not our intention to define protocols. We added a list of gaps and tools so as to avoid ambiguity. * Greg: if we extend the scope of the document compared to the original definition, it will postpone the publication of the document. * Carlos: When you are talking about the time aspect, let’s not try to reinvent, use what helps us solve the problem. Need to take some basic assumptions, and discuss these in the document. The work of this draft is not intended to define the content of the OAM packets. * Greg: if we list existing or future solutions, the work on the document will never end. * Sam Aldrin: if you do not discuss the possible tools, it is very difficult to understand the document. * Greg: it is the task of the authors to explain what they are trying to solve, and how they do it. * Sam: the draft should define what are the possible solutions that are currently available in the IETF. * Carlos: we want to move forward. We encourage comments on the list. Multi-layer OAM for SFC Networks -------------------------------- Presenter: Greg Mirsky Slides: https://www.ietf.org/proceedings/99/slides/slides-99-sfc-multi-layer-oam-for-sfc-00.pdf Draft: https://tools.ietf.org/html/draft-wang-sfc-multi-layer-oam-09 Summary: * This is just a brief presentation. For details, read the draft. * The draft discusses OAM at multiple layers. * Echo request and reply are also discussed in the draft. Return Path in SFC OAM ---------------------- Presenter: Ting Ao Slides: https://www.ietf.org/proceedings/99/slides/slides-99-sfc-return-path-for-oam-00.pdf Draft: https://tools.ietf.org/html/draft-ao-sfc-oam-return-path-specified-00 Summary: * The goal is to define an SFP as the return path of Echo Reply. * The draft defines a new TLV that specifies the return SFP. * Comments and questions are welcome. SFC Path Consistency OAM ------------------------ Presenter: Ting Ao Slides: https://www.ietf.org/proceedings/99/slides/slides-99-sfc-path-consistency-oam-01.pdf Draft: https://tools.ietf.org/html/draft-ao-sfc-oam-path-consistency-00 Summary: * COAM is intended to verify the path consistency. * Uses COAM Echo Request and Echo Reply. Performance measurement with the alternate marking method in SFC ---------------------------------------------------------------- Presenter: Greg Mirsky Slides: https://www.ietf.org/proceedings/99/slides/slides-99-sfc-performance-measurement-with-alternate-marking-for-sfc-00.pdf Draft: https://tools.ietf.org/html/draft-mirsky-sfc-pmamm-01 * Alternate marking can be used to measure loss, delay, delay variation in SFC. * One or two bits the NSH header can be used for the marking method. * There are two possible methods: double marking (using two bits in the NSH), and single marking (using one bit in the NSH). * There are discussions in IPPM about using a single bit instead of two bits. Interworking of SFC and its underlay network -------------------------------------------- Presenter: Ting Ao Slides: https://www.ietf.org/proceedings/99/slides/slides-99-sfc-interworking-sfc-and-its-underlay-00.pdf Draft: https://tools.ietf.org/html/draft-ao-sfc-overlay-02 Summary: * The draft discusses how NSH can work with split NVEs. Discussion on OAM Presentations by Greg and Ting: ------------------------------------------------- * Sam Aldrin: How do you ensure the OAM packet does not loop to itself through the SF? * Greg: In our model - what do we understand as OAM packet? If it is RFC7799 packet, that is specifically meant for performance, generated and consumed by the SFC domain? * Sam: How do you know all of the SFs in your domain? * Greg: SFF to SF is a different layer of OAM. SFF indicates what type of OAM is supported. With an active OAM - yes. With alternate marking method you do not need to do that. * Sam: I am still confused. If you are sending packet that traverses through SFs? * Greg: SFP OAM does not need to touch SF, only SFFs. This information can be obtained from SF by SFF and reported. * Sam: In other words you are not testing the SFC. * Joel: There was in the earlier version of the framework that we do not want to test the functionality of the SFs. * Sam: If you are sending a packet, it is traversing SFs. * Joel: We have to move on. * Stewart: In alternate marking you can use different values rather than dedicated bits. * Greg: there are various ideas of how to save bits. * Stewart: You may want to consider different values. * ZhongHua Chen: In the deployment of SFC the management can be divided into 3 parts: underlay, SF and SFF layer. We have many tools for management, but in the SFF layer we have little tools, therefore it is important to discuss this. SFF management is different from SF management. * Greg: interesting proposal. * Adrian Farrel: It sounded that the proposal would trace through SFF and not trace whether the specific SF was called in. What worries me is that SF can be remote to SFF via the tunnel. I mean monitoring the SF at the end of the connection. It is not enough to trust the tunnel where the packet got to, but is the SF at the end is the SF that I thought of. * Greg: What we are proposing is that the query request triggers the query to mapped SF, but it is not necessarily the same packet that has to traverse. * Adrian: I hear that. Do you trust SF to tell the truth? * Joel: The other path is in-situ OAM. Those are not the only tools at all, just the ones that are being proposed to consider. * Kent Leung: There may be issues with load balancing. That needs to be taken into account. We do not have support of the Ethernet NSH? * Joel: We are not mandating any transports, but it is reasonable to expect that people will be using MPLS as transport, IP as transport, and other transports too. The question of how NVE receives Ethernet frame is not SFC problem. When the overlay is collocated then the SFF may be aware of the overlay and may use that to the benefit. * Kent: If can work on any overlay, but I am not sure whether it is supported over native IP. Operating the Network Service Header (NSH) with Next Protocol "None" -------------------------------------------------------------------- Presenter: Adrian Farrel Slides: https://www.ietf.org/proceedings/99/slides/slides-99-sfc-nsh-with-next-protocol-none-00.pdf Draft: https://tools.ietf.org/html/draft-farrel-sfc-convent-02.txt Summary: * The purpose is to be able to send NSH with metadata, but no payload. * This can be done by assigning "none" to the next protocol. Discussion: * Jim: if the SFF is the last SFF, then potentially the next protocol is important. * Adrian: Good point. If you strip the header and do not know how to forward it, better not forward it. * Dean Bogdanovic: OAM is one of the first use cases I had in mind. * Adrian: yes, but the working group may have other ideas. * Carlos: I find this useful. What is per-flow metadata? * Adrian: the question could be: how do I find which flow this metadata applies to? You need some information in the packet that indicates this. * Jim: per SFC or per SFP? * Adrian: either one or the other. * Dave Dolson: do you think we should define how a proxy forwards the ‘none’? * Adrian: we hope that NSH will be published soon, and do not want to hold it back. This should be documented. * Dave: I suggest the draft is wrong. * Adrian: My view is different. * Kent Leung: Question on flow metadata - how would SFF support per flow metadata. * Adrian: In the load balancing case specifically, normal user packet is picking between a number of SFs. If there is a state that needs to be installed that state need to go everywhere or the load balancer needs to be state aware. * Joel: This document defines how to send metadata to everything. Let’s not hang up to trying to elaborate all the possible things. * Adrian: You are naming a good point that if you have load balancing among SFFs that are stateful you either install state everywhere or keep it with the packet. * Kent : We can talk more in details, but it may break the SFF that is supporting multiple instances of SFs. Use Case For Handling Dynamic Chaining And Service Indirection -------------------------------------------------------------- Presenter: Debashish Purkayastha Slides: https://www.ietf.org/proceedings/99/slides/slides-99-sfc-use-case-for-handling-dynamic-chaining-service-indirection-01.pdf Draft: https://tools.ietf.org/html/draft-purkayastha-sfc-service-indirection-00 Summary: * Service indirection is performed by changing the SPI and SI. * The current draft proposes to perform indirection without reclassification. Open Mic -------- * Tal: I want to bring the issue of MD type 1. When NSH was originally defined it was with type 1, then different formats were defined for type 1, some of those drafts have expired. One of the ways could be not to adopt any of those drafts. Another way to be to choose a subset of those MD format types, up to vendors and operators, Another way would be to have a single document that would define all MD type 1 supported, and other one that has all not supported. It is important to decide which way we are going. * Jim: To clarify - you are concerned specifically with MD type 1? * Tal: Yes. * Mohamed Boucadair (Med): we discussed this on the interim. It is valuable to publish the MD Type 1 format. Authors are encouraged to push these forward to the working group. If we want interoperability it is going to be a bit of a problem. MD Type 2 is a different story: there is a single document that defines the current TLV, and also other documents that define other TLVs. * Jim Guichard: the chairs have an action item to adopt at least two of the documents. We will talk to the authors and encourage them to update the documents and ask for WG adoption. There is one or two additional documents that we need to discuss further on the mailing list. The chairs will take this action. * Adrian: is the current NSH document ready? * Carlos: we spent a lot of time to get it to version 14. I believe the document is ready for publication. There is one open issue: allowing hybrid MD Types within an SFP (receiving MD Type 2 / sending MD Type 1). * Jim: Hopefully we are at the state where document is really ready. * Med: document is stable. Good work was done. There are some issues. Maybe we should add the None value of the next protocol to the current document. It should not delay the publication. Another issue is that the current document says that the value 0x0 is reserved, but does not explain why. We should go over the document, and see if there are any open issues like this that need to be addressed. * Carlos: I believe we fixed the problem with the reserved value. Otherwise we can fix. Working group should see the big picture, which is that the document is nearly ready. * Jim: propose specific text about the None value of the next protocol, and this can be taken with the editor. * Joel: new issues tend to come up. We will integrate this into the document only if we can do it quickly. * Kent: Reverse packet generation draft. We should revise that and start implementing interoperable. We understand the tradeoffs. One option is using SI as showing the direction of the flow, and the other option indicated the direction via SI. I see more leaning towards second option. * Jim: take it to the mailing list. We need to progress. * Greg: Definition of OAM: we had a discussion about the ‘O’ bit. Today we were discussing active OAM, and hybrid OAM. The question is what the ‘O’ bit indicates: active OAM, or any OAM? * Joel: the ‘O’ bit indicates there is OAM significance in the packet. It does not say what the special processing is, and specifically, it does not indicate whether it is active OAM or another type. There is a question here that the framework document needs to address: do we want a single indication that distinguishes between active OAM and other types of OAM? * Greg: in active OAM you can either include the OAM packet in the payload, or use next protocol ‘None’ with metadata. * Joel: if we agree on the mechanisms, the hardware can be triggered by the ‘O’ bit. It does not matter which solution we will choose, the ‘O’ bit is just the trigger to use the mechanism. * Greg: the framework document should specify this.