Minutes IETF101: sfc
minutes-101-sfc-00

Service Function Chaining (SFC)
IETF 101 - London
Wednesday, March 21, 2018
9:30-12:00 (UTC+00:00)
Chairs:
Note Taker: Dhruv Dhody
===============================

Introduction and agenda bashing (WG chairs) - [10 minutes]

Joel Halpern: When sending emails to the mailing list, please remove the
individual email address; as manual approval from chairs is needed for posting
them, slowing things down.

NSH Encapsulation for In-situ OAM Data (Frank Brockners) - [15 minutes]
        https://tools.ietf.org/html/draft-brockners-sfc-ioam-nsh-01

Greg Mirsky: Are you saying that IOAM is not interested in using the O bit?
Active OAM also does not use O-bit! Frank Brockners: IOAM does not change the
meaning of O bit. Customer traffic should not set the bit, but OAM traffic
should. Greg: What is the the OAM traffic? Frank: As per 8300, its a packet
with O bit set. We are not the right person to answer that question. Jim
Guichard: A valid question but Frank is not the person who need to answer that.
Frank: This was raised before, the key is that we are not changing the meaning
of O-bit

<Frank talked about the two proposal for MD type 2 and the next protocol to get
feedback> Joel: Difference b/w next header and TLV is clear esp with respect to
efficiency. There is a compatibility drawback for next header where existing
SFs would drops user packet and things would break! Greg: We also have
Multi-layer active OAM, and to use a header which is a shim for NSH, it would
be good to converge the encapsulation. This was discussed in the overlay design
team discussion, (discussed in NVO3). There is not much difference b/w active
and hybrid OAM and we should try to have a single encapsulation. Kyle Larose:
Might be a good idea to support both? Incrementally we could move to next
protocol! Frank: We started with MD-Type 2 and hardware folks were not happy!
That is why we are in this limbo! Joel: If you have both with multiple next
header, it gets messier and lose the advantages as we go skipping through next
headers! Greg: Hybrid and Active OAM should not exist in the same NSH. Joel:
Hybrid with proof of transit and some thing else could exist. Greg: We could
limit this to one. Frank: What happens with followup packets and classification
would be issue. Greg: Followup packet is just Hybrid OAM and no customer data.

Haoyu Song: NSH is not transport protocol, so why OAM is defined here?
Joel: This is touching on the usecase, next presentation!

<Note in the minutes: Continue to have discussion on IOAM and OAM on the list>
<A humm on what is the preference in the room from encapsulation point of view
-  (1) As a TLV MD-Type 2 (single blob); (2) Next Header!  - [in conclusive
humm]; >

Joel: Doing it both ways is trouble.

Proof of Transit (Frank Brockners) - [15 minutes]
        https://tools.ietf.org/html/draft-brockners-proof-of-transit-04

Kent Leung: There is value here. What happens for traffic that change direction
mid path? Frank: Currently it is unidirectional, and done on per flow basis
rather than per session. We can use the same secrets on both directions. Kent:
In case of mid-path case, when the packet goes in other direction, is this case
legitimate? Frank: It is a bit of a corner case, it is a bit of mess, you need
to maintain session state and cache it. You need a large cache.

Greg: What the intended status/track for this I-D?
Andy Mallis: This is experimental at this moment
Greg: There is proposal in IPPM and it would be good to see them both in the
same track. Alia: Good to see this work back in WG for security/privacy; and
hope for a more mature solution that can be standards track in future. Alia:
Try to get consensuses on a single solution, work on consensuses. Andy Mallis:
There is no mention of IOAM in draft, can this is implemented in MD-Type 2
metadata? Frank: Yes

Sumandra Majee: In higher order service, there is no correlation between
packets and service rendered. As packet could be aggregated and not all packet
reaches the destination. Frank: Lets discuss this offline. Kyle: There could be
a 2nd class of packet that are generated? Kent: Lets take that offline and
discuss more Frank: If you LB, secrets can be shared across SFs and apply the
same action on the packets.

Joel: Hmmm for (1) A Single solution for Transit but no-order (low
computational) or (2) A single solution for Transit and order both (higher
computational) or (3) Both solutions <(2) was noticeable less than (1) and (3)>
Joel: Will take it to the list

SFC OAM for path consistency (Ting Ao) - [15 minutes]
        https://tools.ietf.org/html/draft-ao-sfc-oam-path-consistency-02

Joel: Clarification for - (1) SFF can do load-balancing or (2) SFF is connected
to a loadbalancer which further loadbalance to multiple instances. Who are you
expecting to know and return? Greg: SFF is responding, so information visible
to SFF is returned. Joel: Be careful of the language you put in the I-D Kent:
My understanding is that it is always from SFF perspective. Kent: Does the
message has flow information as well? Maybe returning of SF instance as a
sub-type.

Kyle: Are you carrying the ID of every SF instance that could be reached?
Kyle: I am worried about amount of state in your messages to carry in a packet.
Greg: Each SFF responds to query.
Kyle: I am worried about the SFF load-balancing case and if there are 100
instances, there would be lot of state to return in the packet. Greg: So far
all SF are listed in the same reply, we could think of a mechanism to split it.

Joel: If you need to check RSP, you need to include flow information! Please
add clarifications before we poll for adoption.

Alternative Handling of Dynamic Chaining and Service Indirection (Debashish
Purkayastha) - [15 minutes]
        https://tools.ietf.org/html/draft-purkayastha-sfc-service-indirection-02

Joel: What is path forwarding? This is a term not used in IETF/IEEE.
Debashish: It is identification of E2E path and forwarding based on that?

Sumandra: Opposed to see yet another resolution point should be avoided (if it
can be done by DNS, use DNS). In the example, based on URI, path is found, this
has been done before for example, page routing used by FB. Another way to do
this would be that, if each node is a classifier and point to the next point in
graph. I am confused if this is just an alternative or you have some big
advantage? Debashish: It is an alternate. Kyle: Is this is control plane or
data plane solution? Debashish: Service request (HTTP) is encapsulated in the
NSH, based on name decide the service endpoint. Jim: Instead of program SFF
with nexthop, you use name and resolve it via HTTP Joel: But HTTP doesnt do
that, it is DNS and you also mentioned an alternate to DNS. We are not doing an
app layer protocol. Debashish: HTTP is just an example. Joel: We deal with user
packets and not the application layer stuff. Got to be generic here. Debashish:
The chain would be based on names. So in the chain you have example.com goes to
one.com, two.com and would be resolved by SRR. Kyle: Describe in terms of SFC
terms and not in new terms that are described. Jim: Be clear on the problem
that you are trying to solve? Why the current SFC WG work would not work in
edge computing environment. Kyle: Slide said that Path as an address? I think
it is a property of control plane. Joel: Would not like to do DNS lookup at
line rate as packets are coming in! Kyle: I think of this as just an
implementation of SFC and does it require all this new terminology.

Dirk Trossen: We have lot of functionality in SRR that we offloaded. We need to
clarify how to scope this correctly. [Explanation] As part of the project work
we outsource the behavior into SRR, but we need to think about how this could
be integrated with SFF itself. Kent: We could achieve this by existing
mechanism. You have an assumption here that SFF would need to be stateful,
which needs to be captured for your case.

Service Function discovery in fog environments (Carlos J. Bernardos) - [15
minutes]
        https://tools.ietf.org/html/draft-bernardos-sfc-discovery-00

Joel: Can you clarify who use this discovery? End terminal usually dont worry
as it is transparent to it. Carlos: Terminal is an active participant in the
SFC. Joel: In your case, the end user is invoking the SFP, in SFC it is usually
classifier. This should be clarified.

Kyle: This is cool. Does the terminal acting as classifier? Can this function
be moved to a access point? Carlos: Yes it is acting as classifier. Can be
thought about the access point (depends on dynamicity). Kyle: Have you thought
of up-link case. Can the information about up-link be provided? Carlos: A
general consideration for multiple attachment, this is something to think about.

AOB

Adrian Farrel: There is MPLS-SFC draft in MPLS WG, we are not trying to piss on
NSH. We want to reuse the SFC architecture for a niche deployment.

Closing (WG chairs) - [5 minutes]