Subject: [sfc] New draft posted: draft-rijsman-sfc-metadata-considerations

From: Bruno Rijsman <[email-masked]>
Date: Thu, 13 Feb 2014 09:14:23 -0500

Yesterday I posted a new draft "Metadata Considerations"
(draft-rijsman-sfc-metadata-considerations-00):

https://datatracker.ietf.org/doc/draft-rijsman-sfc-metadata-considerations/

This draft discusses the topic of metadata in the context of Service
Function Chaining.  It aims to:

   - identify use cases for metadata,
   - to define the problem space for metadata signaling,
   - identify candidate approaches,
   - describe the key challenges,
   - and guide the exploration and comparison of possible solutions.

The goal of this draft is *not* to propose a specific protocol but rather
to identify the requirements and solution space before we deep-dive into
any particular approach.

With that in mind, my questions for the mailing list are:

   - Are there any additional use cases for metadata beyond the three
   identified in chapter 2 of the draft?

   - Are there any additional signaling approaches beyond the five
   identified in chapter 3 of the draft?

   - Are there any additional challenges with respect to metadata signaling
   beyond the 13 identified in chapter 4 of the draft?

-- Bruno

---

From: "Ken Gray (kegray)" <[email-masked]>
Date: Fri, 14 Feb 2014 03:23:40 +0000

Hey, Bruno.

My personal answers to your questions would be:

Use cases - no, though the last use-case seemed to suggest actually using metadata to carry a policy (more a configuration function) than as a trigger of that policy/action at the function ..which I don't think is a likely scenario (and, while interesting, would make the metadata problem huge, IMO).

Methodologies – no, any others I can think of would be derivative of what you describe.

Challenges – I can't think of more and really only see a couple as needing redress in this forum IF we assume that imbedded metadata would be the preferred way forward.  Those would be (IMO):

   o  Support for metadata-unaware service function

   o  Preserving metadata through metadata-unaware service functions

   o  Metadata encoding

   o  Multiple sources of metadata

   o  Extensibility

…and I think the first and second will devolve into the same issue (eventually).

If you have a moment for a more general commentary (to my point about the assumption that imbedded metadata would be the preferred way forward) …

In spite of your intent and unless someone comes up with a more compelling case for doing so, I can't see why we would forestall the pursuit of the proposed metadata encapsulation in the header.

None of the described alternatives are clear winners over imbedding metadata in the header (and I would argue incongruent signaling is compatible and optional even if we decide to imbed in the header).  In fact many have clearly stated limitations that make them non-starters.

I agree that IP options are a non-starter because of the well known performance ramifications you hit in one, clear sentence in 3.1.  Both IPv4 options and the use of other well-known header fields, including the use of tags of any sort will also suffer a limitation (IMO) in expressiveness unless they seriously overlap their intended functionality.  Their IPv6 brethren (extended headers) are not that functionally different than imbedding the metadata in the SFC header and limited solely to the IPv6 solution.  Not to go too far down this path, but a solution per-address family or forwarding mechanism also doesn't appear to be the short road to standardization (an immediate n-way fork in the road).

Rewriting all the applications (3.2) to imbed metadata spreads the burden over a huge field (all application programmers) and I have to see that as a potentially bigger obstacle to standardization and deployment.  It seems to substitute one-time standard solution at the network level with an x-many number of application level standard solutions.

Any congruent or non-congruent signaling protocol creates a potential state monster and implies at least the same level of integration in the service function as the imbedded approach with the additional burden of having to maintain a separate communication channel in the application/function.  These solutions invite other problems: response loop problems (which can be shifted to a distributed database problem, admittedly) and subscriber management problem (particularly if a subscriber comm channel fails in a non-obvious manner …the avoidance of which …heartbeats, liveliness detection at the comm level …are an even FURTHER complication) that would then require a bunch of behavior definitions and additional standardization.

The architecture authors HAVE discussed a non-congruent approach using an out of band server (e.g. IFMAP server) and that alternative is still a deployment alternative if you desire.  The existing header proposal provides a beneficial, standardized key for lookups (your chain ID).  You can opt to not use the metadata fields (zero them out at your classifier) in deployment.

While your description of the challenge to a proxy is appropriately gnarly.  I'd argue that a proxy can/should have the option to (at least) recal the original metadata used at original classification (by invoking said metadata from the same source as the original classifier).  While this does touch on some of the problems with the incongruent approach, it wouldn't be (again, IMO) as large an overall impact to scalability and performance as a totally incongruent approach.

The biggest challenge to all the methodologies may be in computed metadata, certainly for the proxy in the imbedded metadata scheme.  Unlike the incongruent/congruent methodologies, however, you can add the metadata without out of band signaling so a server.  So, in a future world where the sfs aren't using proxies (a potentially far horizon, admittedly) this may become an even greater advantage and in the interim might be addressed as a deployment problem (chain construction problem if you have to use proxies and your chain contains elements that may need to use computed metadata of a predecessor) - I'd be interested in opinions as to whether this is as big a corner case as I think it may be.

Thanks for your time and thanks for throwing the metadata ball out onto the field….

From: Bruno Rijsman <[email-masked]<mailto:[email-masked]>>
Date: Thursday, February 13, 2014 6:14 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [sfc] New draft posted: draft-rijsman-sfc-metadata-considerations

Yesterday I posted a new draft "Metadata Considerations" (draft-rijsman-sfc-metadata-considerations-00):

This draft discusses the topic of metadata in the context of Service Function Chaining.  It aims to:

  *   identify use cases for metadata,
  *   to define the problem space for metadata signaling,
  *   identify candidate approaches,
  *   describe the key challenges,
  *   and guide the exploration and comparison of possible solutions.

The goal of this draft is not to propose a specific protocol but rather to identify the requirements and solution space before we deep-dive into any particular approach.

  *   Are there any additional use cases for metadata beyond the three identified in chapter 2 of the draft?

  *   Are there any additional signaling approaches beyond the five identified in chapter 3 of the draft?

  *   Are there any additional challenges with respect to metadata signaling beyond the 13 identified in chapter 4 of the draft?

-- Bruno