Subject: Re: [sfc] SFC Metadata: Comments regarding draft-vallamkonda-sfc-metadata-model-00.txt

From: "Elzur, Uri" <[email-masked]>
Date: Fri, 1 Apr 2016 22:55:55 +0000

Sunil

To advance your point, it may be of advantage, IMHO, if you provide a concrete example of what metadata can be shared, and requires interoperability among vendors, in a specific example e.g. FW LB NAT (or choose your favorite). Notice some proposed directions in your draft.

The thread reads very theoretical and suggests limited value for inter vendor interaction. Seems like you wish to counter it. A specific example may help bring the conversation down to ground level. 

Thx

Uri ("Oo-Ree")
C: 949-378-7568

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Sunil Vallamkonda
Sent: Wednesday, March 30, 2016 11:04 AM
To: Joel M. Halpern <[email-masked]>; Dave Dolson <[email-masked]>; Bottorff, Paul <[email-masked]>; [email-masked]
Subject: Re: [sfc] SFC Metadata: Comments regarding draft-vallamkonda-sfc-metadata-model-00.txt

Joel,

Good point, we are not trying to enumerate all the possible algorithmic behaviors.
Yes, the proposal addresses both vendor and standardized metadata, where latter could be a flavor of former.
In below MD-2, ignoring all metadata is a simple implementation, though with limited capabilities. However in all elements the sender and receiver need to co-ordinate metadata in a dynamic and scalable way to take intelligent actions. 

Re: #1: Is there a definite limitation in framework for metadata to be same for all packets ? It should not limit or mandate either way.
Re: #2: If there is no need for receiver to understand the semantics across vendors and products and releases, I do not believe  it would be a scalable solution. The code semantics and actions need to be aware by elements for metadata, without which we might well use only 'reserved' part of header or just treat MD-2 as a 'reserved' header itself, IMHO.

Again to clarify, the intent and focus is have the ability to understand and extend metadata semantics for deployment. The goal is not to enumerate every possible situation but to provide semantics to customize and support algorithmic and other situations as individual case may be.

Thanks,
Sunil

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]]
Sent: Wednesday, March 30, 2016 10:56 AM
To: Dave Dolson <[email-masked]>; Sunil Vallamkonda <[email-masked]>; Bottorff, Paul <[email-masked]>; [email-masked]
Subject: Re: [sfc] SFC Metadata: Comments regarding draft-vallamkonda-sfc-metadata-model-00.txt

In terms of copied information, control tells the SF what to copy.  It does not matter what the granularity is.

Given that "flow" does not have a consistent meaning (sometimes it means 5-tuple, sometimes it means other things) trying to define control instructions at other granularities than packet gets us into algorithmic behaviors.  And I do not think we want to try to enumerate all of the "supported" algorithmic behaviors.

Similarly, if the information is not the same as that from the prompting packet, we are again finding ourselves getting into algorithmic instructions (maybe you complement this field, or add 100 to that field, or bounce the third field off the roof.)

If we neeed algorithmic behavior, it seems to me that the SF has to know what it is doing.  It can not rely on control to tell it.  Yes, this places some limits on generality of inserting metadata in produced packets.  I would be interested in improvement, but I have not seen one.

Yours,
Joel

On 3/30/16 1:47 PM, Dave Dolson wrote:
> Joel,
> I'd like to examine this point of yours:
>> 2) Metadata to be copied from a prompting packet.  This would seem to 
>> be provided by control as a list of type codes, with no need to 
>> understand semantics.
>
> Yes, I think control should provide information about different type codes.
> But we believe there *is* some requirement to understand certain semantics.
> E.g.,
> - is the metadata about the packet, about the flow or about the source or destination end-point?
> - is the metadata important enough to add to new packets, or is it optional?
> - is the metadata direction-specific, or can the value be cloned from a request to a response?
>
> If we don't address different types of semantics, I think we need to 
> agree there is only one type that works in all cases, or that certain 
> types should not be used in an opaque manner, or that certain types should not be used with service functions that need to inject packets.
>
>
> Personally, I think that per-packet opaque metadata is problematic and probably to be avoided.
> E.g., a metadata that is checksum of the packet.
> If this is opaque to a function, the function may modify the packet or 
> clone the metadata from one packet to another without being able to update it.
>
> -Dave
>
>
> -----Original Message-----
> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: Wednesday, March 30, 2016 1:27 PM
> To: Sunil Vallamkonda; Bottorff, Paul; Dave Dolson; [email-masked]
> Subject: Re: [sfc] SFC Metadata: Comments regarding 
> draft-vallamkonda-sfc-metadata-model-00.txt
>
> I think you are mixing two concepts.
> There is vendor metadata and standardized metadata.
>
> I do not think anything in the framework I have seen will make vendor 
> metadata interoperate without coordination between vendors.
>
> And as far as I can tell, there is nothing needed from the framework 
> to make standard metadata interoperate.
>
> That leaves the corner case of experimental or developmental metadata.
> Experiments almost always need coordiantion.
>
> If we are talking about MD-2, it seems to me that SF and SFF will 
> simply ignore any metadata that they do not understand.  In the common 
> case, SFF will ignore all metadata entirely.
>
> You have raised the question of what metadata shoudl go on packets 
> originated by service functions.  This seems to be a complex question, 
> that is not helped by the framework.  As far as I can tell, I can see 
> the following cases:
> 1) Metadata about the SF originating the packet.  This is common 
> across all packets, and can be provided to the SF by control means in 
> an opaque blob.
> 2) Metadata to be copied from a prompting packet.  This would seem to 
> be provided by control as a list of type codes, with no need to 
> understand semantics.
> 3) Metadata derived algorithmically from information available to the 
> service function.  This is hard.  I do not see how the framework helps 
> here at all.  Is it needed?
>
> Yours,
> Joel
>
> On 3/30/16 1:06 PM, Sunil Vallamkonda wrote:
>> When metadata is exchanged between SFFs, SFs, SFCs, it begs to the questions of interpretations. Without a framework for opaque metadata, the ambiguity between vendor products in service chain makes it incompatible unless the resolution is hardcoded across of releases and platforms, and vendor specific information encoded.  The flexibility and ability for metadata to be interoperable and scale are benefits that are much needed for rapid deployments and adoption.
>>
>>
>> Thanks,
>> Sunil
>>
>> -----Original Message-----
>> From: Joel M. Halpern [mailto:[email-masked]]
>> Sent: Wednesday, March 30, 2016 9:46 AM
>> To: Bottorff, Paul <[email-masked]>; Dave Dolson 
>> <[email-masked]>; Sunil Vallamkonda <[email-masked]>; 
>> [email-masked]
>> Subject: Re: [sfc] SFC Metadata: Comments regarding 
>> draft-vallamkonda-sfc-metadata-model-00.txt
>>
>> I don't see why we would specify which metadata is of interest to a specific SF.  It is up to the SF what it is interested in, not up to service chaining to control that.
>> As for preserving forwarding addresses, while I see value in doing so for some transports, I don't see how SFC can mandate that since it is a transport dependent behavior.
>>
>> Yours,
>> Joel
>>
>> On 3/30/16 12:31 PM, Bottorff, Paul wrote:
>>> Hi Dave and Joel:
>>>
>>> IMHO the most important thing to standardize is how an SFs couple to a chain. We are already implying that it would be desirable for SFs to pass both chain forwarding addresses and meta-data from ingress to egress (proxy forwarding always comes with a cost), however this alone does not provide enough guidance for SF network interfacing. We also have issues like how forwarding reversals are indicated at L4-Higher SFs and what meta-data is opaque and what is for SF consumption.
>>>
>>> Cheers,
>>>
>>> Paul
>>>
>>> -----Original Message-----
>>> From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
>>> Sent: Tuesday, March 29, 2016 7:30 PM
>>> To: Joel Halpern Direct <[email-masked]>; Sunil 
>>> Vallamkonda <[email-masked]>; Joel M. Halpern <[email-masked]>; 
>>> [email-masked]
>>> Subject: Re: [sfc] SFC Metadata: Comments regarding 
>>> draft-vallamkonda-sfc-metadata-model-00.txt
>>>
>>> Joel,
>>> Consider a Service Function that needs to inject a packet, such as 
>>> articulated in https://tools.ietf.org/html/draft-penno-sfc-packet-02
>>> The question arises, what metadata should be put in the NSH header of an injected packet?
>>>
>>> Without some kind of rigorous description of a type of metadata, I don't know how to program the Service Function to do it properly.
>>>
>>> The alternative is to hard-code each service function with the supported types of metadata.
>>> This wouldn't allow a function to handle metadata it wasn't programmed for.
>>>
>>>
>>> So unless there is some easier way of understanding this, there seems to be a gap in specifying Service Function behaviour.
>>> This is one thing we're trying to figure out.
>>>
>>>
>>> -Dave
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: sfc [mailto:[email-masked]] On Behalf Of Joel Halpern 
>>> Direct
>>> Sent: Tuesday, March 29, 2016 7:37 PM
>>> To: Sunil Vallamkonda; Joel M. Halpern; [email-masked]
>>> Subject: Re: [sfc] SFC Metadata: Comments regarding 
>>> draft-vallamkonda-sfc-metadata-model-00.txt
>>>
>>> It may help to see some use cases.
>>>
>>> But it sounds, at best, like a specific control plane solution to some set of problems.
>>> Specific control plane solutions, as distinct from descriptions of requirements, are out of scope for the working group.
>>>
>>> Yours,
>>> Joel
>>>
>>> On 3/29/16 7:32 PM, Sunil Vallamkonda wrote:
>>>> The focus is ability for vendor compatibility and extensibility in SF eco-system without hardcoding and human guessing.
>>>> The categorization and rest may or may not be a fallout of this.  Without such a framework, it makes interpretations harder across implementations. This would be normal case rather than exception, IMHO. The goal is not to standardize any vendor data, but provide a framework to promote vendor compatibility and extensibility across systems.  As a clarification we can walk through use cases to understand the benefits.
>>>>
>>>>
>>>> Thank you,
>>>> Sunil.
>>>>
>>>> -----Original Message-----
>>>> From: Joel M. Halpern [mailto:[email-masked]]
>>>> Sent: Tuesday, March 29, 2016 4:20 PM
>>>> To: Sunil Vallamkonda <[email-masked]>; [email-masked]
>>>> Subject: Re: [sfc] SFC Metadata: Comments regarding 
>>>> draft-vallamkonda-sfc-metadata-model-00.txt
>>>>
>>>> I am sorry.  I don't see the value in this.
>>>>
>>>> Trying to categorize metadata does not seem to help anything.
>>>> Trying to standardize a descriptive langauge for metadata seems to imply something that can consume such a language.  I can not imagine anything that can usefully consume this.
>>>>
>>>> I can understand how a human being would use a registry (which we have to have) to know what T codes are defined, and where to find descriptions of their meaning.
>>>> But that meaning description is going to be in English.  A file that tells me that value 17 is the Dragaeran Corporate type code for Houses does not tell me anything.
>>>>
>>>> The only corner case for the YANG is if my system has some understanding of the semantics of various pieces of metadata, but wants to know what code is associated with a particular usage.
>>>> The problem is that we have mutliple different protocols that may want to provide that information, so all that SFC can define is that the control system must include a way to provide that information.
>>>>
>>>> Given that much of the metadata is not vendor specific, the structure seems very odd.
>>>> ANd it seems likely that any vendor specific metadata will need the semantics to already be known, since we can not standardize that.
>>>>
>>>> Yours in puzzlement,
>>>> Joel
>>>>
>>>> On 3/29/16 6:33 PM, Sunil Vallamkonda wrote:
>>>>> Metadata is a vital element of SFC and thus NFV.
>>>>>
>>>>> Additionally,  interoperability and vendor support challenges need 
>>>>> to be addressed in a scalable and adaptable way for rapid deployment.
>>>>>
>>>>> In January we uploaded draft-vallamkonda-sfc-metadata-model-00,
>>>>> which proposes terminology for talking about metadata in an extensible fashion.
>>>>>
>>>>> If there are no objections, we'd like to start pushing this 
>>>>> terminology into drafts about NSH and the control-plane.
>>>>>
>>>>> Please let us know what you think.
>>>>>
>>>>> Thank you,
>>>>>
>>>>> Sunil.
>>>>>
>>>>> ==
>>>>>
>>>>> A new version of I-D, draft-vallamkonda-sfc-metadata-model-00.txt
>>>>>
>>>>> has been successfully submitted by Sunil Vallamkonda and posted to 
>>>>> the IETF repository.
>>>>>
>>>>> Name:                 draft-vallamkonda-sfc-metadata-model
>>>>>
>>>>> Revision:            00
>>>>>
>>>>> Title:                    Information Model for SFC Metadata
>>>>>
>>>>> Document date:              2016-01-28
>>>>>
>>>>> Group:                Individual Submission
>>>>>
>>>>> Pages:                 9
>>>>>
>>>>> URL:
>>>>> https://www.ietf.org/internet-drafts/draft-vallamkonda-sfc-metadat
>>>>> a-
>>>>> m
>>>>> o
>>>>> del-00.txt
>>>>>
>>>>> Status:
>>>>> https://datatracker.ietf.org/doc/draft-vallamkonda-sfc-metadata-mo
>>>>> de
>>>>> l
>>>>> /
>>>>>
>>>>> Htmlized:
>>>>> https://tools.ietf.org/html/draft-vallamkonda-sfc-metadata-model-0
>>>>> 0
>>>>>
>>>>> Abstract:
>>>>>
>>>>>         Various types of metadata are applicable to Service 
>>>>> Function Chaining
>>>>>
>>>>>         (SFC).  A Service Function (SF) needs information about 
>>>>> all metadata
>>>>>
>>>>>         passing through it.  The metadata could be used to convey
>>>>>
>>>>>         preprocessing information about the packet by other nodes 
>>>>> and an SF
>>>>>
>>>>>         can attach post processing information as deemed necessary.
>>>>>
>>>>>         The purpose of this document is to rigorously define the 
>>>>> classes of
>>>>>
>>>>>         metadata and provide a vocabulary and information model for metadata.
>>>>>
>>>>>         Each item of metadata refers to a subject, examples of 
>>>>> which are IP
>>>>>
>>>>>         endpoint, flow or individual packet.
>>>>>
>>>>> Please note that it may take a couple of minutes from the time of 
>>>>> submission until the htmlized version and diff are available at 
>>>>> tools.ietf.org.
>>>>>
>>>>> The IETF Secretariat
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> sfc mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/sfc
>>>>>
>>>
>>> _______________________________________________
>>> sfc mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/sfc
>>>
>>> _______________________________________________
>>> sfc mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/sfc
>>>

_______________________________________________
sfc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sfc

---

From: Dave Dolson <[email-masked]>
Date: Sun, 3 Apr 2016 23:19:23 +0000

On a related note, draft-penno-sfc-packet discusses how to inject
packets, with a section on metadata. I have proposed the following
replacement section 7, adding these specific classes of metadata,
with examples:
1- Service-Path-Invariant Metadata
2- Service-Path-Default Metadata
3- Bidirectional Clonable Metadata
4- Unidirectional Clonable Metadata- 
5- Service-Function-Mastered Metadata
6- Metadata from Reclassification

I believe draft-vallamkonda-sfc-metadata-model is useful in modeling
metadata.

Proposal for draft-penno-sfc-packet:
-----------------------------
7.  Metadata

   A crucial consideration when generating a packet is which metadata
   should be included in the context headers.  In some scenarios if the
   metadata is not present the packet will not reach its intended
   destination.  Although one could think of many different ways to
   convey this information, we believe the solution should be simple and
   require little or no new Service Function functionality.

   We assume that a Service Function normally needs to know the
   semantics of the context headers in order to perform its functions.
   But clearly knowing the semantics of the metadata is not enough.  The
   issue is that although the SF knows the semantics of the metadata
   when it receives a packet, it might not be able to generate or
   retrieve the correct metadata values to insert in the context headers
   when generating a packet.  It is usually the classifier that inserts
   the initial metadata in the context headers.

7.1.  Service-Path-Invariant Metadata
	
   In order to solve this problem we propose the notion of service-path-
   invariant metadata.  This is metadata that is the same for all
   packets traversing a certain path.  For example, if all packets
   exiting a service-path need to be routed to a certain VPN, the VPN id
   would be a path-invariant metadata.

   To implement this, the controller needs to configure appropriate
   fixed values of the metadata present in the context headers for each
   path identifier in each Service Function that needs to inject
   packets.  The Service Function must store this information so that
   when the Service Function generates a packet it can insert the
   minimum required metadata for a packet to reach its destination.

   A disadvantage to path-invariant metadata is that it is a type of
   metadata that adds no information beyond the information available in
   the path identifier itself.  The corollary is that if different
   metadata is required, a different service paths must be created.

7.2.  Service-Path-Default Metadata

   We also propose the notion of service-path-default metadata.  This is
   metadata that could vary for different packets on a path but has a
   default value acceptable for any packet injected onto a certain path.
   For example, metadata might indicate a quality-of-service (QoS)
   treatment, and an operator considers it acceptable for injected
   packets to have a default QoS treatment.  It might also be considered
   acceptable to not send a particular type of metadata.

   To implement this, the controller configures appropriate default
   metadata values for each path identifier in Service Functions that
   need to inject packets.  The controller may also indicate a
   particular type may be omitted.  The Service Function must store this
   information so that it can insert the minimum required metadata for a
   packet to reach its destination.

   The disadvantage of this approach is that it relies on the assumption
   that there is a meaningful default metadata value, which may not
   exist.

7.3.  Bidirectional Clonable Metadata

   Some types of metadata may use values applicable to both directions
   of traffic.  An example is routing domain, for which an identifier
   indicates a private network such that the value is the same for both
   directions of traffic and may be copied from one packet to another.

   To implement this, the controller must indicate to each Service
   Function that a particular metadata type is bidirectional-clonable.
   The Service Function can therefore clone the metadata value from one
   packet to a new packet that it creates, even in the reverse
   direction.  For this type, it is also considered safe to save a copy
   of metadata for the transport flow.  (E.g., to retransmit a TCP
   packet using metadata cloned from another TCP packet of the same
   connection.)

   Note that the Service Function need not know the meaning of the
   metadata; it just needs to know it is safe to clone in this manner.

7.4.  Unidirectional Clonable Metadata

   Some types of metadata may use values applicable to only one
   direction of traffic, but a value may be cloned from one packet to
   another in the same direction.  An example is a destination
   identifier, in which meatadata indicates a network egress point.
   Another example is metadata indicating a property of either the
   source or destination end-point of the packet.

   To implement this, the controller must indicate to each Service
   Function that a particular metadata type is unidirectional-clonable.
   A transport-layer-stateful Service Function can therefore save away
   metadata values that it has witnessed.  An injected packet can
   therefore be assigned a clone of metadata taken from an earlier
   packet going in the same direction.  For example, a Service Function
   can send a TCP packet using metadata cloned from another TCP packet
   of the same connection and direction.

   Note that the Service Function need not know the meaning of the
   metadata; it just needs to know it is safe to clone in this manner.

   A disadvantage of unidirectional clonable metadata is that a device
   cannot respond to a packet unless it has previously witnessed a
   packet for the same connection in the opposite direction.  For
   example, a firewall cannot respond to the first packet of a
   connection (since both directions have not been witnessed).  However,
   having seen a full hand-shake, a cache or optimizing proxy can inject
   or retransmit packets.

7.5.  Service-Function-Mastered Metadata

   The easiest case to reason about is a type of metadata for which the
   Service Function can provide the appropriate values: specifically the
   metadata that it would be responsible for inserting for all packets
   as part of packet processing.  We can assume this is configured by
   Service-Function-Specific methods.

7.6.  Metadata from Reclassification

   Finally, if the packet needs crucial metadata values that cannot be
   supplied by the methods above then a reclassification is needed.
   This reclassification would need to be done by the classifier that
   would normally process packets in the reverse path or a SFF that had
   the same rules and capabilities.  Ideally the first SFF that
   processes the generated packet.

-----Original Message-----
From: Elzur, Uri [mailto:[email-masked]] 
Sent: Friday, April 01, 2016 7:56 PM
To: Sunil Vallamkonda; Joel M. Halpern; Dave Dolson; Bottorff, Paul; [email-masked]
Subject: RE: [sfc] SFC Metadata: Comments regarding draft-vallamkonda-sfc-metadata-model-00.txt

Sunil

Thx

Uri ("Oo-Ree")
C: 949-378-7568

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Sunil Vallamkonda
Sent: Wednesday, March 30, 2016 11:04 AM
To: Joel M. Halpern <[email-masked]>; Dave Dolson <[email-masked]>; Bottorff, Paul <[email-masked]>; [email-masked]
Subject: Re: [sfc] SFC Metadata: Comments regarding draft-vallamkonda-sfc-metadata-model-00.txt

Joel,

Thanks,
Sunil

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]]
Sent: Wednesday, March 30, 2016 10:56 AM
To: Dave Dolson <[email-masked]>; Sunil Vallamkonda <[email-masked]>; Bottorff, Paul <[email-masked]>; [email-masked]
Subject: Re: [sfc] SFC Metadata: Comments regarding draft-vallamkonda-sfc-metadata-model-00.txt

Yours,
Joel