IETF89 London SFC Agenda

Total time: 2.5 hours

0.00 Introduction (WG-chairs) - [5 minutes]
        - Review of charter priorities

/* Meeting starts 9:04 local time */

Jim: There’s been some hiccups with the slides but are sorted out now.
Thomas: This is the NOTE WELL reminder, especially about IPR. If you are not sure, research further.
… this is a quick summary of the agenda. Short discussion on problem statement, then longer on use cases.
… then requirements and motivation for the header. Last minute requests for the agenda?
… we might not accommodate it because there’s a very packed agenda. We cannot have discussions on everything.
… Only the main documents. A high level comment: It’s not about a deep dive on the technology, only deliverables
… on the charter. A lot of discussion is about how we consolidate docs. Next slide.


00.05 SFC problem statement discussion - [10 minutes]

      Purpose: Are there any outstanding issues? can we start WGLC with goal of
      sending to IESG [milestone April 2014]

        - Problem statement review (Thomas Nadeau) - [5 minutes]
                * http://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/
        - Problem statement Q&A (open-mic) - [5 minutes]

/*
 Carlos Pignataro presenting on behalf of Paul Quinn and Tom Nadeau
 Net-net -- document moving along nicely, lots of review, think it is ready for WGLC.
 */


00:15 SFC use case/requirements discussion (WG-chairs, presenters + open-mic) - [70 minutes]

      Purpose: Work towards having a single WG document plus a small number of more
      detailed scenario-specific use case documents. No need for a document on every
      possible use case. Further discuss SFC requirements and how use cases are driving
      those requirements; do we need an overall document tracking requirements?

      Questions to answer:
      1) which document should be the overview document, and what use cases should it
         cover? mailing list discussion suggests draft-liu-sfc-use-cases as the best
         candidate to fulfill this role.


      2) which documents are worth pursuing as standalone WG documents?

        - SFC use case direction and evolution (WG-chairs) - [5 minutes]

Jim: The objective of the use cases is to have input on which use cases need to be included.
… there are quite a few documents, and we need to think about which ones we do need to move forward.
Thomas: The thinking as chairs is that it is useful to have a higher level use case document, and a small number
… of documents covering very specific scenarios. Now we have a general doc and specific use case docs with 
… a lot of overlap. We need to figure out what to do here because overall is problematic.


        - BBF/IETF SFC Liaison (Hongyu Li) - [5 minutes]

Dave Sinicrope: I am not Hongyu Li. There are many orgs looking at SFC. I represent the Broadband Forum. 
…The BBF has a document looking into it. Some caveats: it is a WIP. You can find this document in the liaison page.
… Second, it is a BBF internal document, to drive protocols in the BBF. However, the BBF thought it would be
… useful to share it here. Basically the doc is a set of use cases, identifying technical gaps that will need technical
… specification. Possibly some protocol work. The BBF does not typically do protocol work, the BBF relies on IETF,
… IEEE, ITU, and compiles the docs into architectures than then publishes, like TR-101.
Dave S: The use cases follow a template that you can look at, and this is a list of use cases: CGNAT, parental control,
… etc. The BBF wants the IETF to look into the use cases and comment. The BBF also would like you to consider
… the ones that are useful. The end result should be a liaison to the BBF, containing a list of use cases useful that are
… useful. We’d also like to know that the IETF is considering the use cases. We can coordinate work informally,
… for example, with people that work for companies that are member of the BBF. The ones that are not can use
… the liaison process.
… Questions?

Thomas: Last week we (me, Jim, Adrian) met to talk about the liaison statement. Good news is that we want to
… keep synchronization forward. Also there’s a separate draft on broadband use cases, and that is not tied to the
… BBF work. We need to sort out differences. That doc is not on the agenda today.
Dave S: Thank you.
Kashnabitz ZTE: We receive liaisons from many forums, is there a strategy to prioritize?
Thomas: A liaison is a note from a forum to another. We do not have to prioritize. They are important because we
… have good relations with other bodies. It’s like an email, but formalized for inter-organization. The content is
… easy to deal with.


        - SFC use cases (Shucheng Liu) - [10 minutes]
                * http://datatracker.ietf.org/doc/draft-liu-sfc-use-cases/

Will: This is the generic use case document.
… in a service function chain, you want to direct traffic to some services, like IPS/IDS. I am not going in detail
… in the use cases. Characteristic of a function chain is not frozen in time. Some stageful service function chain 
… like NAT you need to consider.
… We want to identify a set of use cases. 
… In the draft we have two angles to describe use cases. First we have a set of scenarios.
… We have deployment angles for broadband, mobile, DC.
… Going forward there are orthogonal angles. First, over multiple underlay networks. Then, forking. Also,
… bidirectional flow handling, and also also service function sharing.
… That’s it. Background on the draft: large review, many thanks to reviewers. We think the doc is ready for WG doc.
… We heard some positive feedback on the mailing list already.

Jim: Any specific questions?
Thomas: We will have Q&A at the end of the found use cases.

        - SFC long lived flows use cases (Joel Halpern) - [10 minutes]
                * http://datatracker.ietf.org/doc/draft-krishnan-sfc-long-lived-flow-use-cases/

Joel H: Thank you. This is a presentation on a set of use cases that some co-authors think first and I helped 
… put together. Thanks to the co-authors.
… This draft is about a set of related use cases with some coherence. These are about flows with several properties:
… first, long enough that it is interesting to get work well. Do lot of work on 5-tuple for flows that are longer-lived,
… to improve the network behavior. That’s what’s common across these cases. First one is interesting and 
… with technical challenges. Everyone uses firewalls. If you have a long flow going through it but being served
… out of an explicit cache past the firewall, then might be safe. If you can tell that the long flow meets safety
… properties (e.g., media using RTCP), then instead of creating a firewall entry that says “this is OK”, then you can
… have the flow not go through the firewall.
… Caches have long tails. So depending on the flow, based on L2/L3/L4 headers, you can decide if you want it
… in the cache or not.
… After we finished the document, Diego said “here’s another case”. In mobile, a lot of traffic needs to be 
… encrypted. But if the traffic is already encrypted, you might not want to encrypt it again. Sometimes you
… can determine from the port number 443, but sometimes not. Encryptors are expensive.
… The goal, we’d like these use cases adopted by the WG. We are happy to do the work, we do not care where
… they get folded.

Thomas: Quick questions? One observation: this is a scenario type use case, different than others. This is a 
… general use case for the architecture, it is not based on deployment scenario.

        - SFC mobility use cases (Walter Haeffner) - [10 minutes]
                * http://datatracker.ietf.org/doc/draft-haeffner-sfc-use-case-mobility/

Walter: Hi! These are use cases in mobility. TCP and video optimization. HTTP header enrichment, value-added
… services, etc. 
… Our objective: understand importance of SFC, and look at other standard bodies like 3GPP.
… we have draft-00 and draft-01. We talked about use cases about optimization and would ask to have TDF 
… functionality in our version 01. That supports classification more fine-grained.
… Here is an example of video optimizer chain. Starts with coarse classification. Is it video? Otherwise offload it
… around. If it is, send it to the optimizer. There’s a sequence of decisions. 
… Here’s another example: moving from LTE to IMTS cell. You need to reclassify your chain.
… Weaknesses in current deployments: per APN service chaining. Expensive, complex, inflexible.
… Possible solutions? Exchange context with the IETF SFC classifier function. In green, you see a policy for mobile.
… we have to find out how we interface the IETF SFC classifier environment to the content of the mobile network.
… I understand there is no solution yet. How to exchange metadata in these two environments.
… We listed out use cases. We also have SF for fixed, typically a subset of what we’ve seen for mobile.
… We also have to analyze requirements of 3GPP and what we are doing here. And what happens if traffic 
… becomes more and more encrypted. Thanks.

        - SFC DC use cases (Surendra Kumar) - [10 minutes]
                * http://datatracker.ietf.org/doc/draft-kumar-sfc-dc-use-cases/

Surendra: Thanks, we have some co-authors. These are for Data Center. We want to demonstrate DC use cases,
… and the requirements for SFC. Specifically the need for supporting hybrid data centers, using hybrid service nodes.
… Creating the service function deployment from topological considerations. Passing metadata from terminating
… service nodes are load-balancers. This is a key DC consideration. Also to enable flexible multi-tenancy models. 
… Architecture needs to support both tenancy models. Also using sub-SFC. Finally, should also support
… SF capacity scale-out.
… DCs have two primary types of traffic. For sake of completeness there’s also Mobile Gi-LAN, but that’s out of scope.
… We have North-South traffic (branch office or tenant), and East-West is the predominant (between App).
… Three tier: Web-App-DB. The SFC requirements are very different in these cases. North-South triggers East-West.
… Another consideration: how do we treat service nodes/functions. We need to consider when do we bind service
… function type to their instances. Early binding or late binding? We could define SFC with types and bind them
… to the instances dynamically. This allows for scaling service chain capacity.
… Typical service functions in DC focus on the two traffic types that I mention earlier. Two broad categories:
… Access SFC (like one per tenant in an SP environment), and App SFCs (primarily target traffic between applications)
… in the three tier deployment. We could pick and choose service functions from different service nodes.
… The traditional methods are inadequate for today’s requirements. PBR is useful in staring traffic but does not do
… the job. VLAN stitching does not work. And metadata capability — there is none today and that should be
… a requirement in the service function chain. 
… In summary: The DC use case is significant and we request the group to adopt as WG draft and we solicit 
… comments. We want to continue adding details — this started as a macro use case, but now is more specific.

Ron Parker: Question between access and application service function chains. SFC is a new steering paradigm.
… in the app service function chain, in the 3-tier hierarchy, the IP datagrams are terminated in each other. 
… Can you clarify how those things come together?
Surendra: The SFC does not chain depending on Access or App. In either case you have a steering.
Ron: But in App you have datagrams terminating, and functionalities addressing one another. I think it is out
… of scope.
Surendra: How’s that different?
Ron: It is flow through versus flow to. Flow through there would be intermediate functions not there.
Surendra: Same here.
Ron: The three-tier, I am not sure it is in scope.
Surendra: It is not specific to the three-tear, it is just exemplifying.
Thomas: We talked about cases in which an intermediate device terminates a flow, but end to end looks like one
… flow. Like for example NAT. But others are terminated. Is that your question?
Ron: Exactly. Intercepting flow is different than applications addressing each other, not intercepting.
Jim: We are not talking about architecture here, only the use cases. These are helpful things to have.
Surendra: One last comment: you can build a composite SFC. What the end-user sees ultimately is one SFC.
Someone 2: Web App does not need to be unicast. You are not necessarily calling an IP address. You can call
… a DNS name, which can be unicast or not.
Surendra: You have App Firewalls monitoring apps and load-balancers. And service functions already deployed
… separating these tiers.

        - Requirements for SFC (Carlos Pignataro) - [10 minutes]
                * http://datatracker.ietf.org/doc/draft-boucadair-sfc-requirements/

Ron Parker: I am not Carlos. I am presenting the requirements. Basically the pitch here is that we need a requirements
… document. We are trying to break out the core functionalities and use this as a guidepost.
… This is Med’s keep-it-somple.
… The requirements document is fairly simply. It lists 33 generic requirements, 9 SF discovery req, and others.
… It simply is a guidepost. Assumptions: we do not want to standardize what is a service function. We do not want
… to create a registry. Also, we do not want to constrain creativity of vendors.
… There was a fair amount of discussion using SFC as subscriber-aware. It can or it cannot. But also, part of the
… discussion was what is really the meaning of a per-subscriber SFC. In a subscriber aware classification, the
… number of solutions will be finite. In 10 million subscribers, there will not be 10 million solutions.
… The next step on this one is for the WG to decide if we want to have a specific requirement doc, and if this
… doc is the basis for that.


        - SFC use cases/requirements Q&A (open-mic) - [10 minutes]

Jim: Now we will have an open mike session on questions for all presenters. We chairs also have questions for last.
Thomas: Guidance for the WG, we want to understand what we need to do as a WG.
Jim: Also, there will be asking questions on whether as a WG we want to have a separate item as requirements
… and listing those requirements or not. More later.

Linda Dunbar: Question for Walter. Can we show one slide with PCI, TDF, PCRF.
Jim: That will be difficult to show individual slides.
Linda: Curious about the metadata. We use to pass between PCI, TDF, PCRF. There is an interface passing 
… metadata. How is that done today, and how is it different?
Walter: First of all, metadata is used on the mobile side. But also use info from the PCRF. For example,
… as I told you some days before, this slide (slide 7) can be considered metadata in an optimization scheme.
… so is chaining in general. Every service chain will start with a classifier. We want to ensure we have appropriate
… path through the set of service chains which means that we have to support the classifier as a certain set of the
… mobile context in place.
Linda: Can we still use that mechanism to pass metadata?
Walter: Today, you could think of simple protocols like RADIUS or diameter interfaces.
Linda: Can we still continue using diameter to pass metadata.
Jim: Let’s take it offline, I do not want to get into specific details. Why is the TDF interface not acceptable today.
Linda: No, this is very important for the WG because there is a lot of discussion about metadata passing, and
… today we have metadata passing.
Jim: We will get to that discussion, but not on this particular document.
Someone 3: metadata, msec. diameter, hundreds of milliseconds.
Walter: As I already said, we should avoid diameter 

Ken, NTT: How do we do bidirectional service chain? Is there a use case with handling metadata?
Thomas: I think we established that there is bidirectional passing. Your question is about whether have metadata.

Shin Shakoma (Japan - NTT): In terms of controlling incoming and outgoing packets for bidirectional. 
… Is it implementation?
Jim: Does anyone want to comment on that?
Someone 5: Totally implementation issue how to handle that in bidirectional.
Jim: I want to clarify that question. If we assume we require bidir SFC. Is there a control push into the network
… to push bidirectionally or part of the service chain. I have my own opinion.

Lucy Yong from Huawei: I have a comment on how to document the use cases. It is useful to document the use cases
… as a single document with documented use cases.
Jim: One of the questions we are thinking through: if there are more detailed use cases, what do you include?
… we do not want duplication of 2 page documents. Frankly we do not know the answer.
Lucy: One document minimizes the problem. 
Thomas: Do you want one doc period or also additonals?
Lucy: One document period. If there are use cases, you can use appendix.
Thomas: With the current drafts, there is too much content for a single doc.
Lucy: But there is overlap.
Jim: I am not sure we have that overlap. I’ve read the mobility and DC docs in detail, there is no overlap in those.
… but that feedback is important to the WG. My fear is a 100 page doc that we never finish.
Lucy: The main purpose of the use case is to drive architecture and requirements, we do not need 100 page.

Nicoli (Qosmos): Coming back to the discussion on subscriber ID. I am taking a very operational view. I saw in use cases
… coarse and fine grained policies to identify which resources will be used. It is equally important to find network point
… identifier but also fine grained and coarse grained identifiers to where the packet is from. And how to use the packet
… for particular subscribers.

Jeff Haas, Juniper: I support Lucy that we need to take use case docs and summarize in a list of enumerated requirements.
IRS is going through the same thing right now. Braking requirements as a list will help. You can refer to things.

? (China Mobile): We can reference and not talk here. Merge 3 use cases into a general document. Use case 
… discussed here is 3GPP. That’s one recommendation.
Walter: This is not only for 3GPP what’s here. What we see here is a packet gateway, could be a cable model
… gateway. The only remark is that what we need is interfacing between the context on the network side (cable,
… DSL, mobile, etc) so think about abstract interfaces. Carrier network is end-to-end from a used perspective.
… We have to understand the complete environment.
… It's more of a gateway function between the service chain environment with the rest of world.
Someone 6: I agree. That proves we have a general use case. We need a general use case here.

Parviz Yegani: We need to move forward. Maybe the next IETF is that time.

01:25 SFC architecture discussion (presenters + open-mic) - [30 minutes]

      Purpose: work towards having a single WG document. How do we get there? what gaps need
      filling from other existing documents?

Jim: We will shift gears and talk about architecture. We as a WG we need to work towards a single arch document
… per charter. Now we have different architecture documents in different stages. We will have questions at the end.

        - SFC architecture (Paul Quinn/Andre Bellevue) - [10 minutes]
                * http://datatracker.ietf.org/doc/draft-quinn-sfc-arch/

Andre: Paul is not here, so I will be presenting.
… we already merged my document with Paul’s document.
… High level summary of the document: Describe the architecture, without too much detail. It includes
… architectural concepts, principles, but does not include solutions, protocol extensions, etc.
… some of the solutions are on the header draft that comes later.
… Arch Concepts: There are chains, but there are also hierarchies, and chains for graphs. 
… Decisions that come out are policy driven. And SFC versus Service Function Path, is that the latter is the
… instantiation. SFP is the implementation or run time instantiation of the SFC. That’s with interaction of the
… policy and control plane.
… Arch Principles: topology independent is important. Classification is important. And also SFC encapsulation
… needs a way to convey metadata in the data plane, so encap is important because we also have the service
… path identification for forwarding or implicitly as policy decision within the service function
… Major arch components: these are logical components. In implementations they can be combined. These are
… the logical components and relationship between them.
… Small graph about the SFF, SNF, and SF. In the bottom the underlay network to transport packets. Then SNF
… maps and the SFF maps the SF to multiple Service Functions. Like in a DC and hypervisor, you can follow
… the chain through the hypervisor to the SFF. Those are logical components.
… A bit wider view of that: talking the same SNF, SFF, and SF in a logical component, this is a way to represent
… it is bidirectional. We want to show that we can have a different numbers. 
… The document was widely reviewed. And a lot of suggestions for improvement in next version.
… As next steps, we can add examples to exemplify the logical into real model. Also write more text about interaction
… of different nodes. We are also looking at ways to merge these two drafts, that’s the upcoming Q&A, and
… fulfill the milestone of 2015.

Lucy Yong from Huawei: On the Overall Architecture slide, I am glad to see this graph, it is a lot better than what the 
… document shows. Are these pieces the same?
Jim: The question as I understood, we see SFC encap between logical components in this diagram. Is that the same
… thing, and is it mandatory or optional. 
Lucy: Is more about the first one. They use the same name, can be the same or different?
Andre: The same in the context that we use the sea encapsulation. Now since goes through different SFs, the 
… content will be different.
… There is also discussion about stitching and hierarchy, but from the logical arch is the same.
Jim: It tries to show that the encap can go through a lot of different elements, but it does not have to. In legacy,
… the encap won’t be used.

Surendra: I had the same comment as you made, Jim. It is not always that you have an encap between SFF and
… function. With a proxy you can support legacy without using the encap.

Lucy: If you take the SNF part out, what different?
Andre: We want to show the logical components. On implementation can be collapsed or thin. You are thinking of
… collapsing the SNF and network. Others can collapse SFF and SF. But these are logical.

Ron Parker: I need clarification of the responsibility split of SNF or SFF.
Andrew: We heard the comments on the list, we want to improve this.

Parviz Yegani: In this figure, this does not look like an architecture diagram. Too many boxes and lines. If the IETF
… needs to create a protocol, the IETF needs to communicate between two entities. You need to simplify.
… Solution is between point A and point B. There are too many lines here, it is confusing.

Gal from Contextream: The chains and adding the chains to a profile, I did not see HA, hot standby. 
… If one goes down in a mobile
… environment. 
Thomas: That’s a comment on?
Gal from Contextream: On the architecture.

Luyuan (MSFT): Are we developing a new encap?
Thomas: Yes, that’s in the charter.
Luyuan: Let’s consider reuse of existing to simplify.
Jim: We made a point in the charter that if a technology covers requirements, we will use it.


        - SFC architecture & framework (Diego Lopez) - [10 minutes]
                * http://datatracker.ietf.org/doc/draft-boucadair-sfc-framework/

Diego: Let me say that what you’ve seen, according to my view is very similar to what you’ve seen.
… we have achieved very similar conclusions. But they are not equal, we need to align and converge.
… This is something that discussing this morning, this doc has a why we need this and the right context.
… SFC is a common practice, not formalized. And everything is about policy and the service chaining is 
… differentiated between the functions being chained. That is the difference with normal traffic transiting a domain.
… This is important, because initially we had to answer how is this different than normal traffic.
… The main principles: dynamic service processing; it is adapted to the service taking into account the directionality
… of the traffic. Most important is that it is policy driven.
… We want to make this agnostic regarding network transport.
… The logic supporting SFC is fully policy driven and domain specific. You do not need to expose policies outside
… a certain domain. All in control of a single admin authority. There is no requirement for a global SFC logic.
… just to summarize, it is not about involving IANA in this process. You can have many different chains. Controlled
… by a central decision point. We consider there’s operations abstracted, not including implementation-specific
… details. The architecture defines a set of components and how they are connected. We can rely on IP in IP tunnels,
… MAC-in-MAC, SDN off course.
… We add headers, so we need to consider fragmentation. And also DiffServ and ECN.
… There are two main functionalities, how to structure the chain, and how to enforce policy. There are also a 
… number of additional functionalities.
… The raft defines functional elements. Many things will sound familiar with the previous presentation, we have been
… moving in parallel. We define an SFC boundary node, with ingress and egress. An SF Node can run a service
… function. And then classifier.
… Co-locating different functional elements, there’s a lot of choices. The intelligence resides on the PDP, and we 
… do not mandate how to do these policies.
… There is a distinction between SF Identifier versus the SF Locator. You can define the chains and on a separate
… plane you can define the locations.
… There;s a set of deployment considerations, even no protocol extensions and reusing existing headers.
… And a deep analysis of the tagging, using different language (tagging or marking).
… The proposal, adopt this. This is a very good base. But looking at the other doc presented before this, we see
… high degree of commonality. They are not much separated. Part of the other doc can be used to provide common
… conceptual ground. This doc is more detailed. 

        - SFC architecture Q&A (open-mic) - [10 minutes]

Carlos: The docs are very aligned, but the nomenclature diverges and makes it hard to compare. Let’s align that.
… the nomenclature between the two architecture documents need to be normalized.
Diego: Agree. This uses NSC nomenclature.
Jim: Totally agree.

Margaret Wasserman: I agree that the first doc is not an architecture doc, but it belongs in it. This second doc begins to
… describe an arch document, but there’s ways to go. There is no security arch. That’s unacceptable.
Diego: Agree on security.

Lucy: I read and seems that this doc is based on an actual solution. 
Diego: There is no proposal of a protocol, or anything of a PDP. It assumes there is a *place* where you *define*
… policy. But where you use classifiers is open. You identify the functional elements. And the need for a central
… point to express policies. You can rely on dynamic querying PDP, or PDP push data.

Ling (Huawei): Reliability requirements should be considered in this doc.
Diego: Yes, decoupling identifier from locator: if a certain node fails, you keep the identifier. This can be achieved.

Margaret W.: One more comment: it is possible that everywhere when the doc says “enforce”, it needs to say
… “provision”.
Diego: Yes.

Linda: Quinn doc is clear with arch components. This is more detailed on what to include. There’s lot of content
… in this doc. SF Discovery is such a big topic. If you want to discover all, it’s a kitchen sync. So my opinion is,
… focus on the architecture framework. 
Diego: The doc is in the order of 20-30 pages, and discovery is 1/4 of a page. We do not want to write a 100 page
… document.

Thomas: There was a good show of hands that people has read both docs. Do people have opinion on which
… doc is the base? One doc as a base or merge?
… First question: Can we go about picking one? Choice A: We think one is stronger and we can pick it?
… 3 hands. How many people choice B to merge? More than 3 hands.
… We will encourage authors to merge.

01:55 Requirements/motivations for encapsulation functionality - [30 minutes]

      Purpose: review requirements for the SFC service encapsulation and metadata considerations.

        - Metadata Considerations (Ross Callon) - [10 minutes]
                * http://datatracker.ietf.org/doc/draft-rijsman-sfc-metadata-considerations/

Ross: This doc was written by Bruno but he cannot be here. Thanks to Bruno.
… the goal is to understand what metadata is and how we will use it for multivendor networks.
… There is service classification, then SF instances. We need to worry about how we follow a chain through the
… network, and then what info needs to travel with the data plane. It is useful to not lump everything together.
… what else in addition to user data?
… Metadata is data about data. Examples: one is context information about a flow of traffic that is not available
… everywhere in the network. There might be information implicit about where the traffic has arrived or wireless info
… that might not be available later in the network. If it is not avail later, then we need to carry.
… I have a typo. accounting-id needs to be session-id or accounting-id.
… A second is when there is an expensive operation that you could repeat but you do not want to. Like DPI. Do it
… at one place.
… A third case is fine-grained policies. Functions related but not identical. Voice over IP is a chain, video is a separate
… chain, so per application chain if there’s a small number of those. Or fine grained policies about which movies
… I can watch, parental control, etc. If there are many options, you can have a single chain for video and the
… options are in metadata.
… Many options on how to do signaling. One, in-band. Two, application-layer headers like HTTP headers, and routers
… might not look at them. Option 3, congruent out-of-band (going through the same devices) versus OOB which is
… not going through the same devices. One option is a hybrid, and I start to like this idea. Some in band like the 
… session id, and other goes out of band. Some video server says “are you allowed to watch netflix or hulu”?
… This is another slide I meant to update but I goofed. 
… There are a number of challenges, each one covered in detail in the doc. I want to talk about layers. Virtualization
… adds more complexity, so we need to think hard about how to separate stuff and not an agglutinated mess.
… We are here to produce standards that work multi-vendors. The main point of this doc is to raise issues we 
… need to consider as a WG. We welcome comments.

Tony Peel: How does this work with PCE? Orchestrated by a stageful PCE, and they are in the business of 
… orchestrating the PCE. 
Ross: This is a good question, but on the wrong topic.

Jim: I will cutoff questions.

        - Network Service Headers (Paul Quinn) - [10 minutes]
                * http://datatracker.ietf.org/doc/draft-quinn-sfc-nsh/

These are Paul Quinn’s slides, he could not make it.
… this document defines the NSH, with two components: service path selection identifier, and opaque metadata fields.
… The goal is to create a service plane separated from the topology.
… Transport independent also. It introduces OAM into the service chain, and is implemented in various platforms
… including open source.
… The base header is shown here, fairly simple, OAM bit, flags, reserved, PID, service path ID.
… What the service path is it identifies an instance of a service chain. It is not used for transport itself. The network
… layer takes care of getting to the next. There is also the possibility of branching. The index is used to see
… which node is in the path.
… Here’s a simple example. There’s intense id, carries context, and brief description in the draft. One example
… would be user, application, tenant id, which could be carried and go hop-by-hop along TOR switches. 
… as it goes hop-to-hop, it can use different encaps, and this is VxLAN.
… There are also context headers, part set aside for the network, part for the headers. Semantics assigned by the
… control plane. There is allocation suggested in the draft: the separation I showed. It’s most likely it will be
… per application basis — mobility vs. DC environments.
… For an example of the carried metadata. Passing user and application id down to the service function.
… Going forward we want to continue to get feedback and evolve the protocol based on feedback and deployment.
… and also adopted as an SFC encap.

Jim: Technically out of time, but we can take questions.

Joel Halpern: I do think we need a common header with most of these properties, including service path id, and metadata
… as you explained. But you are trying to figure out beforehand the fixed size of metadata. I cannot see that work with
… the use cases. I know people say HW forwarding needs fixed headers, but I do not see how you can know the
… size.

Lucy Yong (Huawei) : I think this is premature. Is the index per chain or path?
Answer: Per path.
Lucy: I think it is very complex per path. I do not think it is the right way.

Dave Dolson (Sandvine): Many service functions modify the packet. Like a firewall responding with a RST packet. If a device needs to
… inject the packet, how does it know which metadata?
Answer: It depends on the application.

Parviz Yegani: There are different apps, mobility, DC, wireline. I agree with Lucy it is premature for this meeting to 
… make a decision on this. The previous presentation by Ross, the WG chair should look at the guidelines for 
… criteria for SFC WG for inband signaling, or combination.
Jim: This doc talks about the data plane encap. If you want to talk about OOB metadata, it is independent. I see
… no issues on progressing independently.
Parviz Yegani: The decision of in band or OOB, decision needs to come on the list.

Thomas: Quiet please!

Luyuan: I have a concern on focusing on one encap at this stage. Second, concerned on HW dependency.
Thomas: We are not focusing on one, there is only one at the table. There is strong agreement we need a header,
… but not agreement how long the fields, etc.
Luyuan: Agree. There might b need for a header, or not.

Someone from Huawei: Why not VxLAN reserved bits?
Answer: Two reasons. First, field size, and second and more important, decoupling of service vs. network. A general 
… encap independent of network topology. 

        - Requirements/motivations Q&A (open-mic) - [10 minutes]

02:25 Closing (WG chairs) - [5 minutes]

Thomas: Thanks.

/* Meeting closing at 11:37 local time */