IETF90 Toronto SFC Minutes 0.00 Introduction (WG-chairs) - [10 minutes] - Agenda bashing, note-well (WG-chairs) WG-chairs: Note-well briefing and review of agenda. - Update on PS progression (WG-chairs) WG-chairs: Problem statement WGLC completed; minor editorial updates required and then a new revision will be sent to IESG for publication. WG-chairs: IPR disclosure was discussed on-list and consensus is to continue moving forward as per our charter. WG-chairs: Chairs acknowledge that they have an outstanding AI to provide a formal response to the BBF liaison statement. This will be done before the next face-to-face meeting in Honolulu. 00:10 SFC requirements discussion (presenters + open-mic) - [20 minutes] Purpose: Discuss how to progress requirements within the WG. Which documents should requirements be included in? How do requirements drive our charter? How should requirements be structured and documented? WG-chairs: Introduction to the topic of requirements. Chairs provide objective of the session is to discuss as a WG how to progress requirements. Is it critical to have standalone requirements? what kind of requirements need to be documented? does a separate requirements document make sense? - SFC requirements discussion (Ron Parker) - [10 minutes] * http://datatracker.ietf.org/doc/draft-boucadair-sfc-requirements/ Ron Parker: (Summary) It is up to the WG to decide if the document is needed. Requirements are necessary to have a proper design. Since last posting, the requirements are grouped according to function. It is intended as a guideline towards architecture. As a next step authors request adoption as WG document. - SFC requirements Q&A (open-mic) - [10 minutes] Thomas Narten: How many people have read the document? many hands raised. Thomas Narten: There are number of trivial requirements. If there are too many trivial, difficult to identify important requirements. Too many MUST NOTS in the document. Ron Parker: Authors are willing to take input. Paul Quinn: no need to have a standalone requirements document. We are already incorporating into the architecture document. (?) - the document is too detailed; losing the forest for the trees. (?) - there are tons of requirements. Authors put many of them as MUST. We need to prioritize what is essential. Thomas Narten: requirements should not say solutions must do this. Requirements should specify architecture must support but not for solution. Ron Parker: Architecture will define high level design. Requirements should make solutions bound to them. (?): there are individual documents capturing various requirements. A standalone document will help. Thomas Narten: My personal take, what is the best outcome when these become RFC’s? Less documents is best. Ron Parker: refers to discussion on list around architecture that seem to be rooted in requirements. Jim Guichard: can’t we incorporate requirements within the architecture document? Yakov (?): we must not make any assumptions in the document. Thomas Narten: better to say here are the assumptions that we made. Linda Dunbar: In SFC there are assumptions like centrally controlled. Nice to have requirements but there are too many. However, good to have requirements based on functional requirements. Architecture document doesn’t cover. Thomas Narten: If the architecture document is not covering, it should. Otherwise it is a problem. Surendra Kumar: we do not need a separate requirements document. Requirements without use cases are not useful. Jeff Haas: question is whether any of these go to RFC - use the Wiki - create a summary document - what artifact do you leave for the future - this drains resources. WG-chairs: 3 questions. 1. Do we want separate standalone document? (roughly 30 hands raised). 2. Should requirements be documented within the architecture document? (roughly 30 hands raised). 3. Do we need requirements at all? (few hands) WG-chairs: vote on requirements document or incorporate requirements into the architecture document - split between separate requirements document and incorporation into the architecture document. 00:30 SFC architecture discussion (presenters + open-mic) - [20 minutes] Purpose: Identify current status of architecture work. How do we get to a single WG document? What gaps need filling from other existing documents? What other documents fall under the umbrella of architecture? WG-chairs: chairs point out the objective for this session is to find a path to a single WG document for architecture. What is the status of the architecture document merge? what gaps need filling from other existing documents? what other documents fall under the umbrella of architecture and should be merged into the single architecture document? - SFC architecture merge (Ken Gray) - [10 minutes] * http://datatracker.ietf.org/doc/draft-merged-sfc-architecture/ Ken Gray presented on behalf of Carlos Pignataro and Joel Halpern. Ken Gray: (Summary) Goal is to provide architecture document to the WG. Lot of discussion about solutions. This documented is the link between requirements and solutions. There is a section about policy and additional architecture concepts. We had new version published. Will be adding more description to the scope, entry and exit points. Will be adding new section about open issues. Architecture components about SFC, SFP. Will be removing network forwarders from the document. There was lot of discussion about elasticity. Joel captured the definition of SFP, which was the major source of discussion on the mailing list. Does that actually address the questions? Will use open issues section to describe any new open issues. Does the wording work? Is it ready for WG adoption? - SFC architecture Q&A (open-mic) - [10 minutes] Thomas Narten: Adoption is to make sure WG work on one document. Doesn’t mean document is done but will be the document everyone will work on. Will spin a new version, to close all the issues discussed. Joel Halpern: will provide definition and description in the document. Yakov (?): One thing which is missing is that the document defines chain multiple times as an ordered list of functions. Missing is the case where they are not ordered. Joel Halpern: Will be willing to look into adding wording to accommodate that. Dave Dolson: About previous comment. Architecture is very prescriptive and lays out clearly. Architecture should clearly say without leaving any ambiguity. There is a value to that. Joel Halpern: You are asking for precision. If we are not clear, then there is a problem, but, as there are a range of deployments, will not mandate to be specific about each. Will just call out the range, rather than being very specific about a solution. Solution can be very specific. Thomas Narten: If you do not agree to the text, propose and WG will decide. Linda Dunbar: Definition is confusing. In routing area we don’t define IP path. Jim Guichard: What part of text is confusing? Linda Dunbar: The text should be simple. Thomas Narten: We are trying to be precise in the definition associated to the term SFP. Ron Parker: This is achieving what it is supposed to. The new text is relaxing the constraints set. Generally support this text but could be descriptive. Thomas Narten: Make sure the description that lays out and folks could understand. Igor (?): In the optical world, we understand Service and Service Path. Is it possible to define SFP is the path taken by the service? Joel Halpern: That doesn’t solve the problem people are having. We need to say the range of specificity of the path. (?): This document statement should be a bridge between PS and Solution. (?): Text is confusing, but do not want to lose the flexibility of this text, if reworded. (?): Appreciative of the text proposed. It will allow us to define a consistent architecture. 00:50 SFC encapsulation - [30 minutes] Purpose: Discuss WG progression of SFC encapsulation. WG-chairs: chairs point out the purpose of the session is to discuss the progress of the SFC encapsulation. What documents exist as candidates for the SFC encapsulation? What are the key differences between existing documents? - Network Service Headers (NSH) (Paul Quinn) - [10 minutes] * http://datatracker.ietf.org/doc/draft-quinn-sfc-nsh/ Paul Quinn: (Summary) NSH defines a data plane header. Allows for the transfer of opaque metadata. Also allows creation of service level OAM. Provided details about the new changes to the header format. Defined variable context space to carry additional metadata. NSH implemented in Open Source community - OVS data plane and OpenDaylight control plane. Several vendor implementations happening as well. Base header and Service path header were described. Service path ID will be consistent for a given service path. Actively developing within Open source community. Jamal (?): Clarification question. If something is running ASIC in the middle, it cannot be processed? Paul Quinn: It does not and is transparent to it. Thomas Narten: It is end-to-end Nicholas (?): How do we detect loops? Do you allow metadata when there is no data on the path? Paul Quinn: It is dependent on the control plane and set ahead of time. For second Q, need to think about it. Sumandra (?): NSH is at the packet level, services implemented at flow level. It does not require NSH for every packet. Paul Quinn: Draft should be updated to include that. Joel Halpern: how the consumers and producers use the four mandatory fields needs better definition. Thomas Narten: Always an issue when there is a packet header but opaque TLV. Paul Quinn: Reason they are opaque, it is very hard to create standard metadata but willing to add text/example to add as reference. Maybe publish environment-specific semantics? - Service Chain Header (SCH) (Ron Parker) - [10 minutes] * http://datatracker.ietf.org/doc/draft-zhang-sfc-sch/ Ron Parker: (Summary) First published in March 2014. SCH proposes TLV. NSH proposes 4-32bit general purposes Metadata fields. Recommend, SCH and NSH merge. Resolve major differences especially regarding fixed size metadata field. - SFC encapsulation Q&A (open-mic) - [10 minutes] John Messenger: Caution regarding creating another registry, particularly a new field that functions like an Ethertype. Pat Dillon: I agree with John. Replicates some of the things which are already identified with Ethertype. Thomas Narten: Has to be carefully to evaluated. Diego Lopez: Concern about security. How do you trust where packets come from? Header should support some kind of signature. Thomas Narten: There needs to be a standard way of defining TLV. Dave Dolson: Glad to see headers merging. Question about bidirectional paths and devices that need to see both sides of the conversation. There can be internal load balancing in an instance. What/how do I load balance based on imbedded information. Paul Quinn: will add text to clarify but how exactly it is done is vendor specific. Jesse (?) Good to see the TLV discussion and could be implemented in HW. Thomas Narten: We need to have a discussion about performance etc. Jim Guichard: Would like authors to discuss offline. Puneet Agarwal: TLV’s in general can be implemented but will be painful and have a significant cost for hardware. Uri Elzur: TLV content should be openly defined. Agrees that we have to talk about how to implement in hardware. 01:20 Service Function Chaining Operations, Administration and Maintenance Framework - [30 minutes] Purpose: Present SFC OAM framework, which is an essential piece of the SFC charter and work areas. - SFC OAM Framework (Sam Aldrin) - [10 minutes] * http://www.ietf.org/internet-drafts/draft-aldrin-sfc-oam-framework-00.txt - SFC OAM Requirements / Framework (Ramki Krishnan) - [10 minutes] * https://ietf.org/doc/draft-krishnan-sfc-oam-req-framework/ - SFC OAM Q&A (open-mic) - [10 minutes] Ron Parker: Connectivity determination is important. Nirupal (?): Do you need support from the underlay? Anoop (?): SF do not process. Only SFC verification. Nicolay (?): Need abstract definition of OAM to develop tools. Joel Halper: Distinguish between Application OAM and other. We are not monitoring applications. Thomas Narten: The WG needs to decide how big a bite out of monitoring we want to take. Sam Aldrin: it's about influencing the architecture; laying out the considerations. 01:50 Open Source SFC - [15 minutes] Purpose: Present a working SFC implementation as a start to investigation into the control / management plane requirements that need to be addressed as part of the SFC charter and reported back to OPS. - ODL SFC implementation (Reinaldo Penno) - [15 minutes] Reinaldo Penno: (Summary) Brief overview of what was done in OpenDaylight. This is a multivendor effort. Keep it simple. All components are modeled in YANG. REST interface is generated from YANG. Demo couldn’t be displayed on the screen. Code is available at OpenDaylight and is open. 02:05 SFC use cases & miscellaneous - [20 minutes] Purpose: Review use case progression. Are further documents needed? What is missing from existing WG documents? - SFC Generic Use Cases (Hongyu Li) - [10 minutes] * http://datatracker.ietf.org/doc/draft-liu-sfc-use-cases/ Hongyu Li: (Summary) First presented at IETF88. Received comments after IETF89. Cut short mobile and DC sections. Added new sections. Use case describing usage of metadata. This will remove the confusion about the usage of metadata, raised for architecture document. As next steps, we have updated the documented and would like the document to be adopted as WG document. - SFC use case Q&A (open-mic) - [10 minutes] Thomas Narten: There was a fair amount of support earlier to have one document. Now there are other use case drafts. It is up to the WG to decide how to go forward. (?): Document is very comprehensive and useful for operators. Ken Gray: Agree with Thomas. With multiple documents its hard to find unique requirements across many. That is what I would like to see. (?) Good for WG adoption. Jim Guichard: How many have read the document? About 20. Thomas Narten: Should we have separate document? How many like to adopt vs not adopt? No clear consensus in the room for adoption. Continue to discuss on-list. 02:25 Closing (WG chairs) - [5 minutes]