Minutes IETF102: sfc

Meeting Minutes Service Function Chaining (sfc) WG
Title Minutes IETF102: sfc
State Active
Other versions plain text
Last updated 2018-07-21

Meeting 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

- 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

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

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

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

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

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

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

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:

Identification of Overlay Operations, Administration, and Maintenance (OAM)
Remote presenter: Greg Mirsky

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

- 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

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