Minutes IETF98: sfc
Service Function Chaining
||Minutes IETF98: sfc
Service Function Chaining (SFC) Working Group Meeting
IETF 98, Chicago
WG Chairs: Jim Guichard, Joel Halpern.
Minutes by Ignas Bagdonas and Tal Mizrahi.
- Note well presented by Joel.
- Chair slides presented by Joel.
- Agenda bashing: no comments.
SFC Use Cases FOG RAN
Presented by Carlos J. Bernardos
- Radio Access Networks (RAN) are becoming virtualized.
- Current draft focuses on applying SFC to Fog RAN environment.
Joel: If you use SFC to implement this scheme, you need to meet the
latency budget and topology. Would that focus on the requirement
for the control plane, or on how to apply SFC architecture onto
Carlos: Both deployment and protocol requirements.
Uri Elzur: Could you share some information on how Fog RAN could use a
more complete solution than just the data plane. Also what are
your thoughts on interoperability?
Carlos: no clear picture yet about solution. Will work on solution
later on. Currently focusing on requirements.
Uri: What requirements do you have for information exchange netween
Carlos: RAN signal quality, load information may affect the operation
Uri: It would be nice to get that information.
NSH Context Allocation: Timestamp
Presented by Tal Mizrahi
Joel: Encouraging to ask questions. There cannot be any more
variations of MD type 1 as it is a fixed encoding and does not fit
the timestamp in.
Tal: You can mix and match timestamp with other allocations.
Joel: The same applies to security draft too.
Greg Mirsky: Can you recapture the purpose of the timestamping?
Are you trying to measure residence time?
Tal: I will try to answer later in my presentation in 10 minutes.
Greg: I would recommend to support NTP timestamp format too. If you
are taking the clock of your hardware that is running IEEE 1588,
you are synchronizing the clock on the forwarding engines and not
necessary on the compute part for the control plane. If you use
NTP this would help inconvergence, although that is trivial.
Greg: Second issue is the consistency of taking the timestamps. If you
are taking timestamps in SW and outside of HW, you may encounter
the inconsistent latency, and the measurements will not be
correct. The latency of control plane packet processing is
nondeterministic and it is hard therefore to say what you are
measurement. It is a stong requirement to take timestamp of first
bit sent and last bit received in HW. Thus you can calculate the
delay and variation of the path consustently and not related to SW
processinf. Gewtting correct data is reallyhard.
Tal: If I understand correctly you are talking about the method of
taking the timestamp.
Greg: Another comment on context switching. 1588 has transparenbt
clock for residence time measurement that allows for accounti ng
of propagartion of PTP message propagation, and using this you can
avoid timestampi ng each packet.
Tal: What you are saying is that we can add additional field?
Greg: No. You can run measurement of the residence time on each node
and you will know the time for switching the context and that will
indicate the delay needed to treat the packet flow.
Joel: Is your assumption that this is used for packets carrying no
Tal: Yes, type 1. Although we are open for discussion. The main point
of this draft is to have timestamps.
Sumandra Majee: Would it be good to have timestamp type field? Why
existing service delay measurement approaches are not applicable?
There are alternative methods to solve this.
Tal: I have addressed that in KPI stamping slide. Different methods
are not necessarily implemented by all vendors.
Sumandra: If I try to debug which particular function is causing the
delay, there is no requirement to have very accurate timestamps,
even TCP timespamp would be sufficient. How operators will
integrate this into the existing analytics tools, and how they
will use this new mechasnism?
Tal: You can use other OAM mechanisms too.
Sumandra: If it is not an absolute requirement, I would prefer not to
have it on my network.
Tal: You should try to convince the WG that type 2 is mandatory.
Greg: You can use SF proxy for that.
Stewart Bryant: I got the impression that these are special packets
and not live packets. You should be timing the time taken to
traverse the function.
Tal: This is on live data. The actual measurement does not have to
be on all the data. Metadata is there for all data packets.
Kyle Larose: Have you considered what it means for reclassification
or in a proxy environment, will you need to redo the timestamping?
Tal: We will need to consider whether if we reclassify we will keep
the old timestamp.
NSH Context Allocation: Broadband
Presented by Praveen Muley
Joel: We have discussed carrying MD 1 and 2 in multiple contexts so
this seems sensible. Are you trying to allocate a class code for 3
GPP, and then use that class?
Adrian Farrel: Once we allocate the class code in 3GPP, isn't
everythig else is not in scope of the IETF?
Joel: Yes. They will ask for the definition of the types.
Adrian: Also for documentation. Having RFC that talks on how to
allocate the class seems to be needed.
Experience designing minimal independent control plane talk
Presented by Sumandra Majee
This presentation describes experience with a minimal SFC controller.
Greg: You have a hash - what specific information of hash are you
looking at? Number of interfaces?
Sumandra: It depends on capabilities of the device. If it can do
address and port hashing only.
Greg: Do multiple capabilities mean which hashing algorithms to use?
If you have multiple available, you need to spelect a specific one
Sumandra: Yes, it is in a minimum configuration.
Kyle/Sandvine: Found this interesting. I have worked on Sandvine's
solution that has skip functionality. Why do you say that you
should not worry about the classification rules?
Sumandra: In mobile use case, the rules are coming from PCRF. For
building the service chain, the rule is required for flow to path
mapping. We need a consistent API for programming the devices in
Kyle: Did you find use for NSH metadata?
Sumandra: Yes. Side benefits of NSH: use NSH metadata instead of
the GXM parts.
Kyle: Would that be in scope?
Sumandra: Yes. We could solve that with some scripting language.
Pedro Martinez-Julia: The skip mechanism is not necessary from the
beginning. You are not building one chain for a long term, you are
building chains dynamically.
Sumandra: Yes, skip is not required, it is good to have. My feedback
from operators that they are not that dynamic. Looking at the
number of the API calls required for setting up the path - that is
a very large number. If you need 10 calls for one element, and you
have n elements, it may be be too large for dynamic chain
building. If some element is overloaded it may be simpler to skip
it than to rebuild an new chain instead.
Pedro: The hgher layer manager can decidse that. Instead of putting in
all orchestration logic into path creation, we can decide that
except of first and last functions, functions in the middle can be
Sumandar: My vendor answer is yes, sure, go ahead and fo whatever you
want. The second answer - it is not bnecessary that dynamic, and
top redirect a flow is simpler.
Pedro: The complexity is coming from inside the box. You need to
reduce the complexity of the implementation, and this proposal
moves complexity from the management plane into control plane.
Kyle: If you video optimizer crashes, you spend 10 seconds to
reprogram the flows, or you drop everything and redo again? If you
redirect the traffic dynamically?
Joel: what I hear from different people - we need more desription of
the problem space.
Jeff G: It would be good to have a draft on that.
Joel: The WG will decide whether it has interest when they see a
Uri: What does this WG want to do to make NSH and SFC in the industry?
What tools do we have to enable broad industry deployment? We have
invested in data plane, PCRF is another interesting optiom. Maybe
we could do something as a liaison, together with opensource
consortiums on what you cann the minimal controller, an
implementation that shows the path. Then we potentially could take
off, now we are the plumbers building something.
Sumandra: Not certain whether that will take off.
Adrian F: This is useful for discussion. I am not certain how much of
that will end as an RFC, draft would be of use for this. The title
of this slide is very different - minimum controller vs minimum
control. The control and magamement plane pieces in a very simple
network in a centralized way makes sense. But in a larger network
out BGP document might be the right solution.
Please take a look at it and provide feedback.
Soumandra: That draft tries to address similar use cases in rather
Joel: There is also a PCE draft that tries to address this.
- Progression of use case documents
- Progression of control plane requirements document
- others (?)
Joel: Other topic that are open and matter to you to discuss?
Kyle: Need to close the TTL discussion.
Joel: Would you like to use the TTL mechanism provided?
Joel: What you said seems to be consistent with my observation of the
WG rough consensus.
Tal: Another topic that was discussed in the interim was making MD
type 2 with length of zero mandartory, and it seemed that there
was consensus at that time. Can we bring that into the
Joel: Seems to make sense. Will need to follow up on that.
Joel: We had discussion on C bit going away. That has implications on
OAM. As far as I know we are looking into the current text as the
agreed that has the C bit. Does someone want to bring that
Jim G: Please read the interim minutes, they have many topics
covered. We captured 20-30 action items on various topics. Me and
Joel we were focusing on at least the NSH action items. TTL was
one of the last items on that list. Editors of the NSH document
were busy lkeeping up with those actions. Use the mailing list for
discussion, lets try to tie those loose ends. We need hel from the
community to do that. We need to be surer that we are pushing the
working group in the right direction. I do not want to go away
from here and have the same conversation in Pgaru egain. There
needs to be a draft about the minimum requirements that need to be
done. We have many discussions on the control plane document and
it semes that it is not clear what nwe need to do.
JimG: One of the things that was a feedback from the interim was on
the metadata. We felt that we should adopt some of the type 1
document and get more eyes on them. If there is no objection then
we will start the adoption. Second was that we wanted to move the
type 2 documents foroward. We came to conclusion that it was
useful to have a document that lists as the of tlvs that can be
described in a short manner without a specific detailed
explanation in separate documents. We looked to get a new editor
for TLV document, Sumandra agreed to do that, that is another
document that is in line for adoption.
Joel: The goal is not to have the single document that control the
assignment of the ciode points, it can be done in other odcuments
too. If we have type 1 document, we can define in that document a
type 2 codepoint that is described there. We are also looking how
to move the OAM document forward. Now that NVO3 is going through
the overlay OAM work, we are looking into how to alight with
them. We are not going to say that we must own because we own
it. We are collaborating with other people ta make things work for
the IETF. Do we need a separate security docuemnt? We did not hear
much support for the document. Please speak on the list.
JimG: Any more burning issues that you have?
Carlos Pignataro: awareness of the work of in-situ OAM (IOAM). It was
presented in various WG during last two IETFs, there is running
code, targetting many applications relevant to many groups. That
work was brought to IPPM, we are targeting the adoption of data
structures document, there seems to be good support for that. The
transport work may happen in different WGs, we may come back to
SFC asking for a code point. One of the drafts, Proof of Transit
(POT), talks about proof of transit in the context of service
chaining. It might be too early at this time, but when it matures
a bit more, we might come asking for adoption. We want feedback on
that. In a mid term we may rerquest for SFC to be a home for POT.
Joel: End of the meeting.
01:55 Closing (WG-chairs)