* 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, Deborah Brungard, Martin Vigoureux | 2013-Dec-20 —  
Chairs
 
 


IETF-102 sfc minutes

Session 2018-07-19 1550-1750: Place du Canada - Audio stream - sfc chatroom

Minutes

minutes-102-sfc-00 minutes



          ===============================
          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.
          
          



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