Service Function Chaining (SFC) IETF 101 - London Wednesday, March 21, 2018 9:30-12:00 (UTC+00:00) Chairs: Note Taker: Dhruv Dhody =============================== Introduction and agenda bashing (WG chairs) - [10 minutes] Joel Halpern: When sending emails to the mailing list, please remove the individual email address; as manual approval from chairs is needed for posting them, slowing things down. NSH Encapsulation for In-situ OAM Data (Frank Brockners) - [15 minutes] https://tools.ietf.org/html/draft-brockners-sfc-ioam-nsh-01 Greg Mirsky: Are you saying that IOAM is not interested in using the O bit? Active OAM also does not use O-bit! Frank Brockners: IOAM does not change the meaning of O bit. Customer traffic should not set the bit, but OAM traffic should. Greg: What is the the OAM traffic? Frank: As per 8300, its a packet with O bit set. We are not the right person to answer that question. Jim Guichard: A valid question but Frank is not the person who need to answer that. Frank: This was raised before, the key is that we are not changing the meaning of O-bit Joel: Difference b/w next header and TLV is clear esp with respect to efficiency. There is a compatibility drawback for next header where existing SFs would drops user packet and things would break! Greg: We also have Multi-layer active OAM, and to use a header which is a shim for NSH, it would be good to converge the encapsulation. This was discussed in the overlay design team discussion, (discussed in NVO3). There is not much difference b/w active and hybrid OAM and we should try to have a single encapsulation. Kyle Larose: Might be a good idea to support both? Incrementally we could move to next protocol! Frank: We started with MD-Type 2 and hardware folks were not happy! That is why we are in this limbo! Joel: If you have both with multiple next header, it gets messier and lose the advantages as we go skipping through next headers! Greg: Hybrid and Active OAM should not exist in the same NSH. Joel: Hybrid with proof of transit and some thing else could exist. Greg: We could limit this to one. Frank: What happens with followup packets and classification would be issue. Greg: Followup packet is just Hybrid OAM and no customer data. Haoyu Song: NSH is not transport protocol, so why OAM is defined here? Joel: This is touching on the usecase, next presentation! Joel: Doing it both ways is trouble. Proof of Transit (Frank Brockners) - [15 minutes] https://tools.ietf.org/html/draft-brockners-proof-of-transit-04 Kent Leung: There is value here. What happens for traffic that change direction mid path? Frank: Currently it is unidirectional, and done on per flow basis rather than per session. We can use the same secrets on both directions. Kent: In case of mid-path case, when the packet goes in other direction, is this case legitimate? Frank: It is a bit of a corner case, it is a bit of mess, you need to maintain session state and cache it. You need a large cache. Greg: What the intended status/track for this I-D? Andy Mallis: This is experimental at this moment Greg: There is proposal in IPPM and it would be good to see them both in the same track. Alia: Good to see this work back in WG for security/privacy; and hope for a more mature solution that can be standards track in future. Alia: Try to get consensuses on a single solution, work on consensuses. Andy Mallis: There is no mention of IOAM in draft, can this is implemented in MD-Type 2 metadata? Frank: Yes Sumandra Majee: In higher order service, there is no correlation between packets and service rendered. As packet could be aggregated and not all packet reaches the destination. Frank: Lets discuss this offline. Kyle: There could be a 2nd class of packet that are generated? Kent: Lets take that offline and discuss more Frank: If you LB, secrets can be shared across SFs and apply the same action on the packets. Joel: Hmmm for (1) A Single solution for Transit but no-order (low computational) or (2) A single solution for Transit and order both (higher computational) or (3) Both solutions <(2) was noticeable less than (1) and (3)> Joel: Will take it to the list SFC OAM for path consistency (Ting Ao) - [15 minutes] https://tools.ietf.org/html/draft-ao-sfc-oam-path-consistency-02 Joel: Clarification for - (1) SFF can do load-balancing or (2) SFF is connected to a loadbalancer which further loadbalance to multiple instances. Who are you expecting to know and return? Greg: SFF is responding, so information visible to SFF is returned. Joel: Be careful of the language you put in the I-D Kent: My understanding is that it is always from SFF perspective. Kent: Does the message has flow information as well? Maybe returning of SF instance as a sub-type. Kyle: Are you carrying the ID of every SF instance that could be reached? Kyle: I am worried about amount of state in your messages to carry in a packet. Greg: Each SFF responds to query. Kyle: I am worried about the SFF load-balancing case and if there are 100 instances, there would be lot of state to return in the packet. Greg: So far all SF are listed in the same reply, we could think of a mechanism to split it. Joel: If you need to check RSP, you need to include flow information! Please add clarifications before we poll for adoption. Alternative Handling of Dynamic Chaining and Service Indirection (Debashish Purkayastha) - [15 minutes] https://tools.ietf.org/html/draft-purkayastha-sfc-service-indirection-02 Joel: What is path forwarding? This is a term not used in IETF/IEEE. Debashish: It is identification of E2E path and forwarding based on that? Sumandra: Opposed to see yet another resolution point should be avoided (if it can be done by DNS, use DNS). In the example, based on URI, path is found, this has been done before for example, page routing used by FB. Another way to do this would be that, if each node is a classifier and point to the next point in graph. I am confused if this is just an alternative or you have some big advantage? Debashish: It is an alternate. Kyle: Is this is control plane or data plane solution? Debashish: Service request (HTTP) is encapsulated in the NSH, based on name decide the service endpoint. Jim: Instead of program SFF with nexthop, you use name and resolve it via HTTP Joel: But HTTP doesnt do that, it is DNS and you also mentioned an alternate to DNS. We are not doing an app layer protocol. Debashish: HTTP is just an example. Joel: We deal with user packets and not the application layer stuff. Got to be generic here. Debashish: The chain would be based on names. So in the chain you have example.com goes to one.com, two.com and would be resolved by SRR. Kyle: Describe in terms of SFC terms and not in new terms that are described. Jim: Be clear on the problem that you are trying to solve? Why the current SFC WG work would not work in edge computing environment. Kyle: Slide said that Path as an address? I think it is a property of control plane. Joel: Would not like to do DNS lookup at line rate as packets are coming in! Kyle: I think of this as just an implementation of SFC and does it require all this new terminology. Dirk Trossen: We have lot of functionality in SRR that we offloaded. We need to clarify how to scope this correctly. [Explanation] As part of the project work we outsource the behavior into SRR, but we need to think about how this could be integrated with SFF itself. Kent: We could achieve this by existing mechanism. You have an assumption here that SFF would need to be stateful, which needs to be captured for your case. Service Function discovery in fog environments (Carlos J. Bernardos) - [15 minutes] https://tools.ietf.org/html/draft-bernardos-sfc-discovery-00 Joel: Can you clarify who use this discovery? End terminal usually dont worry as it is transparent to it. Carlos: Terminal is an active participant in the SFC. Joel: In your case, the end user is invoking the SFP, in SFC it is usually classifier. This should be clarified. Kyle: This is cool. Does the terminal acting as classifier? Can this function be moved to a access point? Carlos: Yes it is acting as classifier. Can be thought about the access point (depends on dynamicity). Kyle: Have you thought of up-link case. Can the information about up-link be provided? Carlos: A general consideration for multiple attachment, this is something to think about. AOB Adrian Farrel: There is MPLS-SFC draft in MPLS WG, we are not trying to piss on NSH. We want to reuse the SFC architecture for a niche deployment. Closing (WG chairs) - [5 minutes]