Minutes IETF100: sfc

Meeting Minutes Service Function Chaining (sfc) WG
Title Minutes IETF100: sfc
State Active
Other versions plain text
Last updated 2017-11-25

Meeting Minutes

Service Function Chaining (SFC)
IETF 100 - Singapore
Tuesday, November 14, 2017
9:30-12:00 (UTC+08:00)
Meeting Minutes

SFC WG chairs: Joel Halpern, Jim Guichard
SFC secretary: Tal Mizrahi

Chair Slides
Presenter: Joel Halpern

- Note well applies.
- The agneda for the current session was presented.
- NSH was approved for publication.
- There is some work-in-progress on rechartering. Some initial thoughts may be
presented today, if time permits.

SFC Multi-layer OAM
Presenter: Greg Mirsky

Summary and discussion:
- An update on the multi-layer OAM document was presented.
- Main scope is active OAM, i.e., using test packets being injected for
measurement. - SFC OAM identification is based on a dedicated Next Protocol
value, and the 'O' bit in the NSH. - SFC OAM demultiplexing is another issue,
based on the UDP port. - Kyle Larose: there is also an NSH Ethertype. In NSH
over Ethernet the suggested method is not possible. - Greg: clarification: UDP
encapsulation is inside the NSH. - Echo request/reply is used for connectivity
verification. - An open question is whether we want to use these packets with
timestamps to compute delay. - Kyle Larose: there is a draft that talks about
ways of building the reverse path algorithmically. What about implementations
that use these algorithms? - Greg: good point. There are global flags, that can
be used for various purposes, including optional fields. Timestamp might be one
of them. - Kyle: is that what the TLV is for? - Greg: yes. - Greg: Feedback is
welome. - Kyle: you request a ‘Next Protocol’ value. Should it be a common type
with IOAM? - Greg: different type. We are discussing active OAM. An alternative
approach could be to implement active OAM using metadata, but that is currently
not the proposal we are talking about. - Adrian Farrel: good presentation. It
is good to have the options on the table. Need to throw out some of the
options, and end up with one way. - Greg: that is our intention. We want one
thing that we all agree about. Options are nightmare for implementers. - Greg:
we would like to ask the WG chairs to consider adoption.

Path Consistency in SFC OAM
Presenter: Ting Ao

Summary and discussion:
- COAM stands for consistency OAM.
- An SFF that receives a COAM request forwards it and also responds with a COAM
reply. - Joel: if an SFF is supporting multiple service functions in the chain,
 would it send one reply, or separate replies, corresponding to each SF? -
Ting: it should send a reply for each of the SFs. - Kyle: what if there are
multiple choices for SFs (load balancing). Do we represent the group as one
entity, or is there a response for each member? - Greg: there is a difference
between Joel's question and your question. It is a very useful option which may
be worth to consider. The current proposal does not address that. - Joel: the
SFF may not know how many instances are behind it. We have to be careful. -
John Strassner: this assumes every SFC knows where it is going. What if we have
a policy that requires two service function paths? - Joel: these are separate
service function paths. - John: what if we want to identify different service
paths? - Greg: it is not what we intended in this proposal. We are analyzing a
single SFP. It is not necessarily a 1:1 mapping with RSP. - Joel: there is one
other implication. There may be multiple SFFs from a given SF. How are you
tracing the correct RSP? - Greg: that leads us to another presentation that
Ting will present. We realized that there is no method of identifying RSP
within SFP. We will present a proposal of how to do that. - Kent Liang: it may
be good to clarify the load balancing aspect. If there are multiple instances,
then which one do you respond to? There is a way of selecting, and it may be
stateless or stateful. It may be good to have a section about that. - Greg:
contributions are welcome. - Kyle: how is the implementation for returning the
source address? How do you know if it is valid? - Ting: the source address is
returned in the SFC OAM echo request message. - Greg: if we use echo request /
reply, then we need to use a source TLV to return information about the
address. - Kyle: are you comparing the source address against something else in
the packet? - Greg: there could be a different policy. It is currently out of
scope of the document. There may be other mechanism to authorize the source. -
Kyle: should we reply with an explicit packet specifying that it was denied if
it fails? Otherwise a misconfiguration in the control plane could look like a
problem in the data plane. - Greg: logging some information will be sufficient.
Explicit replies may present a security vulnerability.

Return Path in SFC OAM
Presenter: Ting Ao

Summary and discussion:
- A summary of the updates in the draft was presented.
- Security considerations were revised.
- Joel: if the entity that generates the reply already knows who the source,
then it does not need another validation. It does not add up. - Greg: it is not
a scenario we thought of. If you send a reply to a different sender. - Joel:
you need to rewrite the security considerations. - Greg: we will look into it.
The sender of the echo may be different than the one the response is sent to.

Scalability of SFC
Presenter: Ting Ao

Summary and discussion:
- The draft discusses four scenarios related to scalability: join (SF added to
existing SFC), redundancy, bypass, failover. - Joel: the C1, C2 terminology is
no longer part of the WG terminology. The NSH document has been approved for
publication, so we will only make changes in NSH if there is a very strong
reason. The issues described related to C2 – there does not seem to be anything
new needed here. - Kyle: regarding the NSH extension or metadata for the flow
identifier: first, we do not want to open NSH. Second,the metadata version is
32 bits long, and the other version is only 8 bits long. An 8 bit flow ID is
not enough entropy for load balancing. Strongly suggest to go with solution
that allows more than 8 bits. Another issue that needs to be discussed in the
requirements is what it means to join/leave the forwarding plane with minimal
impact. - Joel: the control plane draft is no longer a WG draft. No need to
comply with it.

Performance Measurement with Alternate Marking
Presenter: Greg Mirsky

Summary and discussion:
- Alternate marking creates a sequence packets that are marked in the same way.
This marking is used for the measurement: loss and delay. - The proposal is to
use two bits from the reserved bits in the NSH for alternate marking. -
Alternate marking is discussed in IPPM. Presented also methods for compact
alternate marking, which minimizes the number of bits used for marking. -
Alternate marking can be used for residence time measurement.

NSH Encapsulation for In-situ OAM Data
Presenter: Frank Brockners

Summary and discussion:
- IOAM is used to carry per-hop metadata in-band in data packets.
- IOAM is being developed in the IPPM working group.
- IOAM encapsulations are being presented in a few WGs, including SFC.
- The ‘Next Protocol’ is used for indicating the IOAM data.
- Kyle: I like this approach. My concern is that a device that does not
understand the ‘Next Protocol’ should drop the packet. - Joel: SFFs are not
supposed to look at the next protocol. - Kyle: yes, but in some cases some
nodes may drop the packet. - Greg: what is the value of the ‘O’ bit in this
approach? - Frank: will be discussed on the next slide. - Frank: our original
open source implementation uses MD type 2. Another option is to use the ‘Next
Protocol’, which is what the current draft proposes. - Frank: it is an open
question whether we want the ‘O’ bit to be set in all IOAM traffic. - Greg: I
disagree with your interpretation of the ‘O’ bit. You can use both the ‘O’ bit
and the next protocol (which tells you what resides next). This is why our
active OAM proposal uses the next protocol, as well as the ‘O’ bit. I would be
happy to get rid of the ‘O’ bit. - Frank: I am just saying that we need
guidance of what a node should do when it receives a packet with the ‘O’ bit
set. - Greg: that is an implementation detail. What do you recommend regarding
the ‘O’ bit? - Frank: the current document proposes to set the ‘O’ bit. - Greg:
are you proposing to use MD type 2 or ‘Next Protocol’? If the latter, then it
looks like active OAM. - Joel: the proposal is for IOAM to have a ‘Next
Protocol’. - Greg: I can recall there were objections about this regarding
active OAM. - Joel: there is an issue about what SFFs do with the ‘Next
Protocol’ if they are unable to process it. We need to call it out in the
document. - Frank: we originally went with the MD Type 2, but decided to go
with ‘Next Protocol’. - Jim: let’s take this issue to the list. - Mickey S:
regarding the ‘O’ bit – the default behavior if you do not support OAM is to
drop the packet. We do not want to use the ‘O’ bit. - Joel: good point. It may
be better to use a reserved bit instead. Let’s discuss on the list. - Frank:
Proof Of Transit (POT) is something to be considered as a security mechanism
for NSH. Should we adopt POT in SFC? - Joel: it is important for the WG to
consider. - Greg: in VXLAN-GPE you do not have a choice but to use ‘Next
Protocol’, right? - Frank: right, we will discuss it this week in LISP. - Greg:
it may be good to understand that in some encaps there are TLVs, and in others
such as VXLAN-GPE it is not possible. We want to be consistent. - Frank: there
is no one solution, since some protocols have the ability to use TLVs, and
others do not.

MPLS Forwarding Plane for SFC
Presenter: Adrian Farrel

Summary and discussion:
- The draft discusses how MPLS can be used for SFC. It is being discussed in
the MPLS working group. - We are looking at environments in which deployed MPLS
routers can be used for creating an SFC, rather than using NSH. - Carlos
Pignataro: it is important to run SFC on existing MPLS data plane. Have you
considered running NSH on MPLS? - Adrian: yes, we have considered it. In this
case MPLS is purely a tunneling mechanism. Still, something has to process the
NSH, which will have to be implemented in software. - Carlos: you mean MPLS in
SFFs, or MPLS in SFs? - Adrian: MPLS in SFFs, which are implemented by MPLS
routers. - Carlos: you are neither doing swap nor pop, right? It looks like
something different. - Adrian: it is very similar to how you process NSH. It is
a swap operation. - Carlos: in NSH, every SF processes the NSH. In your
solution, the SF does not process the MPLS. - Adrian: today, if the SF is not
NSH-aware, we use an NSH proxy. - Carlos: so the SFF is also an SFC proxy? -
Adrian: we will use an SFC proxy, not necessarily in the SFF. - Greg: how do
you use SFC OAM over MPLS? - Adrian: we haven’t yet figured out how to do OAM
in SFC, so it is early to say how it will work with MPLS. - Greg: have you
thought about how to do OAM in this case? - Adrian: yes. - Joel: there is no
‘O’ bit. - Adrian: you can use a GAL label. - Andy Malis: you could have a
special context label that implies there is OAM there. - Joel: as a co-chair I
agree this work would not fit in the SFC WG. - Wim Henderickx: you need to
define how the proxy will work in the stacking case. - Adrian: right, it needs
more intelligence. Just as in NSH, we would need more complicated action here.
- Zafar Ali: special label really depends on the need. We do not necessarily
need that. Perhaps the work needs to be in SFC, and maybe there is no need for
MPLS-specific changes. - Kent: I was reading a draft about segment routing with
MPLS. How is this related to that draft? - Adrian: there are two related
drafts. One is presented next in this session. Another draft is being discussed
in SPRING. - Zafar: segment routing involves MPLS hardware, so it is related to
the current draft.

Service Chaining using Unified Source Routing
Presenter: Shaowen Ma

Summary and discussion:
- The draft proposes a unified approach with MPLS and NSH.
- The NSH is transported over an MPLS network using segment routing.
- Greg: the SFF label can be in an MPLS tunnel which is swapped. You do not
have to specify a classifier. It will be an LDP-based loose source routing.
Looking at this label stack it may be assumed that SFFs are neighbors, but
between them you can have MPLS tunnels that are constructed based on IGP
extensions for SR. - Shaowen: We are considering two alternatives. One options
is to use both L2 and L3. We believe there is a local behavior. - Greg: I hope
that you are using existing IGP extensions. - Shaowen: yes, we will be reusing
IGP/BGP extensions. - Xiaohu Xu: I am a co-author of this draft. I understand
the question was whether we could use an LSP directly instead of LDP tunnels
between SFs. We could directly use MPLS routing for this. But to meet the
transport independence requirement which is important in SFC, we would like to
support multiple underlays: IPv4 or IPv6. - Wim: question – are you proposing a
full proxy on the SFF? - Shaowen: yes. - Wim: you are not proposing for the SF
to process the NSH? - Shaowen: yes, that can be done too. - Adrian: comparing
this to the previous presentation, what is the role of NSH here other than
metadata encoding? What happens with the other fields in the NSH? - Shaowen:
that is up for discussion. We do not require every hop to process the NSH. If
there is a software switch/router that is NSH aware then it can process NSH. -
Adrian: I am concerned that you are using protocol fields that are not being
used. You may want to replace NSH with metadata. - Shaowen: metadata is
important. - Adrian: right, but you only need metadata – no need for NSH. NSH
will cause confusion. - Rober Raszuk: why are we focusing on 5 labels in the
data plane when we can do all the steering in the control plane? Why is this
data plane centric? - Shaowen: we are also looking at the control plane.

NSH Context Header Allocation: Timestamp
Presenter: Tal Mizrahi

- Greg: I suggest to allow support for NTP format as well. PTP is and advantage
for HW implementations, while NTP is more suitable for SW. Another question is
why not use the alternate marking method instead of integrating a timestamp.
Alternate marking does not require accurate synchronization. The Timestamp
metadata puts a stronger requirement on the network because of the
synchronization. - Tal: I would like to see alternate marking - it is a good
method. Measuring delay is only one of the use cases for the timestamp
metadata. There are other use cases which are not covered by alternate marking.
Regrading the NTP format - we have already added it to the draft. - Greg:
alternate marking measures loss as well. - Linda Dunbar: is this intended for
adjacent nodes, or across the network? Will all the network have to be
synchronized? - Tal: we are talking about an SFC domain. When you use
timestamps, you assume there is some kind of a synchronization mechanism. -
Linda: synchronization is very expensive. Would it be possible to support
something without synchronization? - Tal: some of the use cases that are
described in the draft do not require synchronization. However, we believe that
if you are using a timestamp metadata, then it makes sense that your network is

SFC dynamic chaining and service indirection
Presenter: Debashish Purkayastha

- Joel: are you multicasting these packets?
- Debashish: we can have multiple instances of a producer connected to a single
consumer. In that case we may use multicast. - Kyle: I read the draft, and did
not quite understand it. You are using HTTP as a transport – how do you use it?
Is traffic being encapsulated in HTTP? Are you using HTTP PUT? HTTP is not
usually used for carrying traffic. - Debashish: we are using the URL to
identify endpoints. - Kyle: maybe we do not need HTTP, but only naming using
URLs. - Joel: a lot of clarification is needed here. Please take it to the list.

Optimized Service Function Chaining
Presenter: Artur Hecker

- Kyle: question about the SF ID. What if a packet visits multiple times in a
service chain? - Artur: in principle it can work with any ID. We focused on the
transport domain, which ends at the SFF. - Kyle: I am not sure I agree. -
Artur: let’s discuss it offline.

Rechartering Discussion
Presenter: Joel Halpern

Summary and discussion:
- This is very preliminary.
- There are probably too many items for the charter at this point.
- Proof Of Transit (POT) is something we want to consider.
- OAM is another important issue we want to address.
- Security considerations will also be important – integrity and authentication.
- Transport considerations, e.g., what happens when there is congestion?
- Network management – we will need to define YANG models.
- Control plane work, related to BESS and PCE. We are not going to define a
control plane protocol. Our focus is integration and coordination with the
ongoing control plane work in other places. - Interoperation with existing
service chaining mechanisms that precede NSH. - Metadata, including MD Type 2
and MD Type 1. - Collaborate with other working groups that propose work
related to SFC. - Hierarchical SFC solutions. - Feedback from operators and
actual deployments. - Uma Chunduri: segment routing has to be deployed with
NSH. We may need an explicit charter item for SFC with segment routing. - Kent:
operational considerations includes some of the drafts that were discussed in
the past? - Joel: that draft does not seem to be related. Need separate item
for that. - Xiaohu Xu: when defining new encap such as NSH, there are
considerations that need to be considered about how to transport this new encap
over MPLS. - Joel: clearly we do not take the work of the MPLS, but if there
are MPLS-related issues we should identify them. - Wim: interoperability
between SFFs is not possible today, because things are not clearly defined
enough. It would be nice to have that. Specifically, focusing on how NSH works
over Geneve and VXLAN-GPE, from interop perspective. - Artur: I agree. We may
need BCP about interoperability. - Frank: how do you decide on priorities
between items on the charter items? - Joel: Not sure we have enough people and
enough time to work on all items. Good question. - Linda: what kind of OAM are
we talking about? - Joel: we are talking about SFC OAM. Various proposals can
be considered, and it is for the working group to consider. The charter only
specifies the problem, not the solution. - Alia: the question is what do you
need to get the stuff deployed. That is what we need in the charter, so that we
have people working rapidly to get things done. NSH is done now. You can do the
work that you care about, but it requires to put the time and energy to review
the documents and get things done. - Kent: regarding the MD Type 2 metadata.
That is a key item, since SF have to interoperate. - Frank: would it make sense
to have an interim about the rechartering? - Joel: I would like to see
discussion on the mailing list, and then we decide. - Alia: we need the charter
to be done before the next IETF meeting. - Joel: I hope we can do it on the
mailing list.

Adjourned at 11:56