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

From: Sunil Vallamkonda <[email-masked]>
Date: Tue, 29 Mar 2016 22:33:36 +0000

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-metadata-model-00.txt

Status:         https://datatracker.ietf.org/doc/draft-vallamkonda-sfc-metadata-model/

Htmlized:       https://tools.ietf.org/html/draft-vallamkonda-sfc-metadata-model-00

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 29 Mar 2016 19:19:32 -0400

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:
> 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.
>
> URL:
> https://www.ietf.org/internet-drafts/draft-vallamkonda-sfc-metadata-model-00.txt
>
> Status:
> https://datatracker.ietf.org/doc/draft-vallamkonda-sfc-metadata-model/
>
> Htmlized:
> https://tools.ietf.org/html/draft-vallamkonda-sfc-metadata-model-00
>
> Abstract:
>
> 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
>

---

From: Sunil Vallamkonda <[email-masked]>
Date: Tue, 29 Mar 2016 23:32:38 +0000

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

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:
> Additionally,  interoperability and vendor support challenges need to 
> be addressed in a scalable and adaptable way for rapid deployment.
>
> If there are no objections, we'd like to start pushing this 
> terminology into drafts about NSH and the control-plane.
>

---

From: Joel Halpern Direct <[email-masked]>
Date: Tue, 29 Mar 2016 19:36:38 -0400

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

---

From: Sunil Vallamkonda <[email-masked]>
Date: Wed, 30 Mar 2016 01:02:43 +0000

Yes,  it can be de-mystified further and to see extent of also being extensible. 
We can discuss them at IETF 95.

Thanks,
Sunil.

-----Original Message-----
From: Joel Halpern Direct [mailto:[email-masked]] 
Sent: Tuesday, March 29, 2016 4:37 PM
To: 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

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:
> Subject: Re: [sfc] SFC Metadata: Comments regarding 
> draft-vallamkonda-sfc-metadata-model-00.txt
>
>> https://www.ietf.org/internet-drafts/draft-vallamkonda-sfc-metadata-m
>> o
>> del-00.txt
>>
>> Status:

---

From: Dave Dolson <[email-masked]>
Date: Wed, 30 Mar 2016 02:29:38 +0000

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

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 29 Mar 2016 22:35:30 -0400

While I agree we need to specify how service functions inject packets, I
do not agree that we need to fully specify their behavior.   There are
many aspects of their behavior that are not going to be specified, and
other aspects that will be set by control mechanisms which are outside
of our scope.

Even if I want to specify the behavior of service functions, I do not
consider that this draft tells me most of the important things I want to
know.  If I were specifying such behavior, I would need to be able to
describe how the service function is to derive values for metadata, not
just which metadata types and values it should produce (nor which MD-1
encoding it should follow).  That is very hard.  But it is what it means 
to rigourosly specify the metadata.

For the case where wwe want the service function to insert metadata that 
it does not understand, all we need to do is allow control to specify a 
blob of data, which control promises is a TLV sequence or an MD-1 block, 
to be inserted into the packet.  There is no need at all for information 
as to what vendor the type is, or even a distinction between types and 
values.  Just "Here is the extra stuff you need."
I have no problem with a control requriement, for the control interface 
to service functions, that indicates that control (generically) must 
provide that information.

Yours,
Joel

On 3/29/16 10:29 PM, Dave Dolson wrote:
> 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
> 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
>
>> 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
>> 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
>> 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
>>
>>> 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.
>>>
>>> A new version of I-D,
>>> https://www.ietf.org/internet-drafts/draft-vallamkonda-sfc-metadata-mo
>>>
>>>
del-00.txt
Abstract:
>>> 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
>

---

From: Dave Dolson <[email-masked]>
Date: Wed, 30 Mar 2016 02:58:46 +0000

I'm thinking more along the lines of the control plane indicating,
for example, that a particular metadata type is a flow-classification type,
and may be cloned from one packet to another of the same flow.

(And not so much that there is a constant value to be inserted, although that might be a valid type to consider.)

At this point, we're just trying to start the conversation 
with draft-vallamkonda-sfc-metadata-model
I don't think it is finished by any means.

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Tuesday, March 29, 2016 10:36 PM
To: Dave Dolson; Sunil Vallamkonda; [email-masked]
Subject: Re: [sfc] SFC Metadata: Comments regarding draft-vallamkonda-sfc-metadata-model-00.txt

Yours,
Joel

del-00.txt

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 29 Mar 2016 23:18:13 -0400

There are two issues:

1) I have real trouble seeing how what is described in the draft is a 
solution to the problems you describe.

2) As far as I can tell, this is a control plane issue.  The requirement 
we have is that control provide enough information that the service 
function can apply appropriate metadata to packets it generates.  That 
requirement is not currently captured, and should be.

Assuming that some working group was to work on the problem, models 
along the lines described in this draft do not seem accurate or 
appropriate.
I will admit that part of my reluctance is that I have trouble 
conceiving of a useful model for non-static metadata to be generated. 
Maybe a list of "copy these metadata types from the packet which 
prompted the generation?"  But that clearly leaves some gaps.

Static metadata across all generated packets is easy, but probably of 
little utility.

Yours,
Joel

---

From: "Bottorff, Paul" <[email-masked]>
Date: Wed, 30 Mar 2016 16:31:39 +0000

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,

-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

Yours,
Joel

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Wed, 30 Mar 2016 16:37:21 +0000

Paul B.

A clarification below.

> On Mar 30, 2016, at 12:31 PM, Bottorff, Paul <[email-masked]> 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

PQ>  There is no adopted proposal that suggests that NSH participant SFs pass forwarding addresses.  This is a fundamental architecture point.

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

---

From: "Bottorff, Paul" <[email-masked]>
Date: Wed, 30 Mar 2016 16:41:07 +0000

Hi Paul:

To clarify the SPI/SI form the chain forwarding address in the proposed NSH header. We also have other proposals using MPLS stack chain forwarding addresses, MAC, and IP address chain forwarding addresses.

Cheers,

Paul

-----Original Message-----
From: Paul Quinn (paulq) [mailto:[email-masked]] 
Sent: Wednesday, March 30, 2016 9:37 AM
To: Bottorff, Paul <[email-masked]>
Cc: Dave Dolson <[email-masked]>; 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

Paul B.

A clarification below.

> 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

> To: Joel Halpern Direct <[email-masked]>; Sunil 
> Vallamkonda <[email-masked]>; Joel M. Halpern <[email-masked]>; 
> [email-masked]
> Consider a Service Function that needs to inject a packet, such as 
> articulated in https://tools.ietf.org/html/draft-penno-sfc-packet-02
>>> Additionally,  interoperability and vendor support challenges need 
>>> to be addressed in a scalable and adaptable way for rapid deployment.
>>> 
>>> which proposes terminology for talking about metadata in an extensible fashion.
>>> 
>>> https://datatracker.ietf.org/doc/draft-vallamkonda-sfc-metadata-mode
>>> l
>>> /
>>> 
>>> Htmlized:

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 30 Mar 2016 12:45:48 -0400

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

---

From: Sunil Vallamkonda <[email-masked]>
Date: Wed, 30 Mar 2016 17:06:00 +0000

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 30 Mar 2016 13:26:58 -0400

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

---

From: Dave Dolson <[email-masked]>
Date: Wed, 30 Mar 2016 17:47:47 +0000

Joel,
> provided by control as a list of type codes, with no need to understand 

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

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 30 Mar 2016 13:55:36 -0400

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

---

From: Sunil Vallamkonda <[email-masked]>
Date: Wed, 30 Mar 2016 18:03:58 +0000

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:
>> 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.
>
> 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.
>
>
> 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
>
>
> And as far as I can tell, there is nothing needed from the framework 
> to make standard metadata interoperate.
>
> 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.
>
> 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.
>> To: Bottorff, Paul <[email-masked]>; Dave Dolson 
>> <[email-masked]>; Sunil Vallamkonda <[email-masked]>; 
>> [email-masked]
>>>>> https://www.ietf.org/internet-drafts/draft-vallamkonda-sfc-metadat
>>>>> a-
>>>>> m
>>>>> o
>>>>> del-00.txt
>>>>>
>>>>> Status:

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Wed, 30 Mar 2016 18:05:45 +0000

Paul,

I think that's the fundamental misunderstanding: the NSH SPI/SI is not a forwarding address, it is an identifier.

It also bears mentioning, to avoid any confusion: NSH is the WG adopted draft.

Paul Q.

> On Mar 30, 2016, at 12:41 PM, Bottorff, Paul <[email-masked]> wrote:
> 
> Hi Paul:
>