* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Sfc Status Pages

Service Function Chaining (Active WG)
Rtg Area: Alvaro Retana, Alia Atlas, Deborah Brungard | 2013-Dec-20 —  

IETF-99 sfc minutes

Session 2017-07-17 1550-1720: Congress Hall II - Audio stream - sfc chatroom


minutes-99-sfc-00 minutes

          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
          * 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
          * 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
          * The document discusses the OAM requirements and functions. It does
            not define protocols.
          * The document includes a mapping OAM functions to OAM protocols.
          * 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
          * Greg: if we extend the scope of the document compared to the
            original definition, it will postpone the publication of the
          * 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
          Draft: https://tools.ietf.org/html/draft-wang-sfc-multi-layer-oam-09
          * 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
          * 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
          Draft: https://tools.ietf.org/html/draft-ao-sfc-oam-path-consistency-00
          * 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
          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
          Draft: https://tools.ietf.org/html/draft-ao-sfc-overlay-02
          * 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
          Draft: https://tools.ietf.org/html/draft-farrel-sfc-convent-02.txt
          * 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.
          * 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
          * 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
          * 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
          * Service indirection is performed by changing the SPI and SI.
          * The current draft proposes to perform indirection without
          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
          * 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.

Generated from PyHt script /wg/sfc/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -