Minutes IETF98: sfc
minutes-98-sfc-00

Service Function Chaining (SFC) Working Group Meeting
IETF 98, Chicago
Tuesday, 16:40-18:40

WG Chairs: Jim Guichard, Joel Halpern.

Minutes by Ignas Bagdonas and Tal Mizrahi.


Chair slides
============
- Note well presented by Joel.
- Chair slides presented by Joel.
- Agenda bashing: no comments.


SFC Use Cases FOG RAN 
======================
Presented by Carlos J. Bernardos

Summary:
- 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
    these requirements? 

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 
    service functions? 

Carlos: RAN signal quality, load information may affect the operation 
    considerations. 

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: yes. 
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 
    other metadata? 

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

Presentation: 

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?

Praveen: Yes.

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

Summary:
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
    for use. 

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

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

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

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

Joel: There is also a PCE draft that tries to address this. 



Open-mic discussion
===================
Topics: 
- 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?

Kyle: yes. 

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
    specification? 

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
    foirward? 

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)