%% You should probably cite rfc8677 instead of this I-D.
@techreport{trossen-sfc-name-based-sff-03,
    number =    {draft-trossen-sfc-name-based-sff-03},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-trossen-sfc-name-based-sff/03/},
    author =    {Dirk Trossen and Debashish Purkayastha and Akbar Rahman},
    title =     {{Name-Based Service Function Forwarder (nSFF) component within SFC framework}},
    pagetotal = 25,
    year =      2019,
    month =     jan,
    day =       31,
    abstract =  {Many stringent requirements are imposed on today's network, such as low latency, high availability and reliability in order to support several use cases such as IoT, Gaming, Content distribution, Robotics etc. Adoption of cloud and fog technology at the edge of the network allows operator to deploy a single "Service Function" to multiple "Execution locations". The decision to steer traffic to a specific location may change frequently based on load, proximity etc. Under the current SFC framework, steering traffic dynamically to the different execution end points require a specific 're-chaining', i.e., a change in the service function path reflecting the different IP endpoints to be used for the new execution points. This procedure maybe complex and take time. In order to simplify re-chaining and reduce the time to complete the procedure, we discuss separating the logical Service Function Path from the specific execution end points. This can be done by identifying the Service Functions using a name rather than a routable IP endpoint (or Layer 2 address). This draft describes the necessary extensions, additional functions and protocol details in SFF (Service Function Forwarder) to handle name based relationships.},
}