=============================== Service Function Chaining (SFC) IETF 102 - Montreal Thursday, July 19, 2018 15:50 – 17:50 (UTC-04:00) Meeting Minutes =============================== SFC WG chairs: Joel Halpern, Jim Guichard SFC secretary: Tal Mizrahi Meeting minutes: Tal Mizrahi, Johnn Strassner Jabber: Evangelos Haleplidis Chair Slides ------------ Presenter: Jim Guichard Slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-sfc-wg-chair-slides-01 Summary: - Note well applies. - The agenda for the current session was presented. - WG progress was presented. - New RFC: RFC 8393. - Proof of transit was adopted. - Hierarchical SFC was approved for publication. - Frank Brockners: the WG also adopted the IOAM over NSH draft. NSH Encapsulation for In-situ OAM Data -------------------------------------- Presenter: Frank Brockners Slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-sfc-1-nsh-encapsulation-for-in-situ-oam-data-00 Summary and discussion: - The draft was adopted by the WG. - Not much updates to the draft. - In the draft two potential approaches are presented: next header approach vs. NSH Metadata Type 0x2. A question to the working group how to proceed here. Will continue discussion on the mailing list. Proof of Transit ---------------- Presenter: Frank Brockners Slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-sfc-2-proof-of-transit-00 Summary and discussion: - The WG adopted the draft. - Only editorial changes were performed in the last version. - Two possible approaches: Shamir’s Secret Sharing, which does not guarantee order preservation, and nested encryption which guarantees order but requires more resource. It would be preferable to have a single approach. Diego’s proposal (next session) may allow to use Shamir’s Secret Sharing with an extension that guarantees order preservation. May allow simplification of the current draft. Ordered Proof of Transit ------------------------ Presenter: Diego Lopez Slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-sfc-3-ordered-proof-of-transit-01 Summary and discussion: - The target is to guarantee the order by defining an extension that is based on the current POT proposal. - The PoT uses a per-link mask. When a node receives a PoT it uses the ingress mask to verify the PoT, and when sending a mask it uses the egress mask in the outgoing PoT. The mask is simply XORed with the PoT. - The new proposal can be incorporated as a new section in the PoT. - Frank: the mask is not exactly per link, but per node-to-node combination. - Frank: do people like this approach? We can either add it to the draft and continue with two options, or add it as a single option. - Joel: go ahead and add the new extension, and ask on the mailing list whether you can remove the second approach. - Frank: we will do that. Segment Routing for Service Chaining ------------------------------------ Presenter: Francois Clad Slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-sfc-4-segment-routing-for-service-chaining-01 Summary and discussion: - This is not an SFC draft, but the authors would like feedback from the SFC working group. - Greg Mirsky: this question was also raised in the MPLS WG. How do you see the separation of OAM layers between the transport and the service. - Francois: when we do OAM we will analyze the policy. Whether it is a topology segment or a service segment. - Greg: OAM is not only control plane. Are you saying it will be propagated in the data plane? - Himanshu Shah: OAM at different layers – you need to know what SID list you are using. Depending on the SID list you can attach an OAM to the transport or service. - Joel: you may not want OAM packets to be sent through your service. Most applications do not know what to do with OAM packets. There is some complexity in what Greg is asking. - Himanshu: so how does the service OAM work? - Greg: that was my question. It requires attention. - Francois: OAM aspects will require some thoughts. It is even more challenging in MPLS. In SRv6 there is an OAM bit in the header that helps with this. - Himanshu: the train has left the station. There are other drafts in which MPLS labels are used. - Andrew Dolganow: for simplicity we trade off some of the functionality for easier implementation. We need to think about these tradeoffs. Some things will not be possible with this approach. In some cases this tradeoff will make sense, in others not. Need to make this tradeoff clear. - Francois: yes, there are tradeoffs. We will clarify this in the document. NSH and Segment Routing Integration for Service Function Chaining (SFC) ----------------------------------------------------------------------- Presenter: Jim Guichard Slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-sfc-nsh-and-segment-routing-integration-for-service-function-chaining-sfc-01 Summary and discussion: - There was some confusion about NSH vs. segment routing. - This draft discusses the fact that these are complementary technologies. - This draft was presented in SPRING. Will try to push it there. - [Unidentified person, sounds like Carl Dara]: you are defining new behavior. Is this draft standard track or informational? - Jim: informational. - [Unidentified person, sounds like Carl Dara]: but there is no new behavior on the SFF? - Jim: the behavior required is that when you receive the NSH packet, it is not going to perform and NSH lookup, but a segment-routing based lookup. - [Unidentified person, sounds like Carl Dara]: if you have NSH and segment routing, you would have two headers. In which scenarios would this be required? - Jim: The figure in the presentation is an example. Segment routing between data centers is an example in the slides. NSH under the segment routing, because you want to continue the chain between the data centers. - [Unidentified person, sounds like Carl Dara]: in this example the transports are constant. Maybe in brown field migrations this would make sense. But otherwise it would be best to use one header. - Jim: maybe it would make more sense if the ‘red’ transport in the figure would be VXLAN. That would be the best approach in this case. Will change the example. The point is that at this point inside the data center there is no segment routing capability. The chain between the data centers requires the two transports. - Kent Liang: this is a good example. Different types of transport domains. This is a good idea. - Wim Henderickx: I am one of the co-authors of the previous draft that was presented. There is some forwarding behavior on both segment routing and NSH which is specific to this approach, which is similar to Andy’s approach (next presentation). Certain lookups and forwarding behaviors will be affected. This document should be standard track. - Jim: I agree. - Rajiv Asati: the perceived challenges would be that instead of either SFF lookup or SR lookup, now we may need both. That requires more state and complexity. It is worth considering using SR with metadata, so that you do not need to perform two lookups. - Jim: that is an option. It is not possible to implement this without state. I do not think this is a problem. - Rajiv: perhaps you cannot avoid state, but you need simplicity. - Jim: right, we have some more ideas related to this that we plan to add to the draft. - [Unidentified person, sounds like Carl Dara]: there is a change in the forwarding behavior here. It has to be standard track. - Jim: I agree. - Kent Liang: OAM was not mentioned. Should be in the draft. - Andrew Dolganow: the example in the presentation is a good example for the flexibility of this approach. I hope both approaches that were presented here will be discussed in the same forum. MPLS Encapsulation for SFC NSH ------------------------------ Presenter: Andrew Malis Slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-sfc-mpls-encapsulation-for-sfc-nsh-01 Summary and discussion: - This draft was presented earlier this week in the MPLS working group. - Greg Mirsky: RFC 8300 does not define any OAM. - Andy: it defines the OAM bit, which will be used by the OAM mechanisms. - Jeff Tantsura: this will be the bottom of stack label, right? - Andy: it may not be the bottom of stack. There may be an ELI for example. - Jeff: please discuss it in the draft. Network Service Header (NSH) Explicit Congestion Notification (ECN) Support --------------------------------------------------------------------------- Presenter: Donald Eastlake Slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-sfc-7-network-service-header-nsh-explicit-congestion-notification-ecn-support-00 Summary and discussion: - The goal is to collect congestion information, and avoid packet loss except in extreme cases. - Jeff: there is a benefit from being decoupled from IPFIX. - Donald: it seems useful to define a mechanism for this. - Jeff: not everyone supports IPFIX. - Greg: ECN provides congestion indication without quantifying. Do you think measurement can be more informative? For example alternate marking. - Stewart: if we have more powerful telemetry mechanisms, why use ECN when we can do better? - Donald: it is possible to use other performance measurement mechanisms in parallel. - Tal: in the typical use case the CN will be triggered by SFFs and the reaction point will be the classifier? - Donald: yes. Identification of Overlay Operations, Administration, and Maintenance (OAM) --------------------------------------------------------------------------- Remote presenter: Greg Mirsky Slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-sfc-8-identification-of-overlay-operations-administration-and-maintenance-oam-00 Summary and discussion: - This draft was also presented in RTGWG and NVO3. - Any comments will be taken to the list and also to the RTGWG list. Name-Based Service Function Forwarder (nSFF) component within SFC framework --------------------------------------------------------------------------- Presenter: Debashish Purkayastha Slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-sfc-9-name-based-service-function-forwarder-nsff-component-within-sfc-framework-00 Discussion: - Evangelos Haleplidis: is this tied to ICN networks? - Debashish: not really. - Diego: your solution does not use DNS? - Debashish: we mentioned the different ways in the draft. DNS is a way, but we described other ways. - Diego: DNS solution is based on records? - Debashish: yes, it is one of the ways. - Diego: if you are resolving the DNS, you are not taking the decision at the service function level. - Debashish: right, that is one of the problems with DNS, and we do not suggest to use it. - Joel: there is a number of issues that I asked you to address, and I do not see them yet. Having names is a problem in SFC use cases. Caching is of limited applicability. Having tunnels that require TCP setup per packet is very interesting. There are a lot of implications on SFF and is much more complicated than you make it. Multi-domain Service Function Chaining with ALTO ------------------------------------------------ Remote presenter: Danny Alex Lachos Perez Slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-sfc-10-multi-domain-service-function-chaining-with-alto-00 Discussion: - Joel: currently multi-domain support and control plane support are not within the charter of the working group. We are allowing the presentation because it is interesting, but it is not currently within scope. - Dhruv Dhody: there is something called SF-aware topology, so you can compare your approach with that, or use a YANG model to expose the functionality. - Danny: we can discuss it further on the mailing list. - Joel: our charter is restricted to a single domain. Before we work on multi-domain these are interesting questions to think about. Feel free to discuss it on the mailing list, even though it is not currently in the charter. Adjourned at 17:42.