Subject: [sfc] Examples of Metadata that need to be passed among SFs : regarding draft-vallamkonda-sfc-metadata-model-01.txt

From: Linda Dunbar <[email-masked]>
Date: Mon, 11 Jul 2016 16:49:07 +0000

https://datatracker.ietf.org/doc/draft-vallamkonda-sfc-metadata-model/ has the examples of metadata that may need to be passed among SFs along a SFP, e.g.

      SF1 may at real-time attach DoS information for the next SF in downstream. SF1 provides the hint and it is up to the downstream SFs to process it or ignore it. However if a downstream SF chooses to processes, it needs standardized metadata data model to understand the hint encoded by SF1 in packets.

To minimize the extra bytes added to packets in NSH, it is necessary to have compact encoding of the metadata carried by data packets. Achieving this goal will need control plane to inform the encoding mechanisms to SFs via out of band control channels.

What do people think about the proposed framework for metadata exchanged among SFs on a SFP?

Linda

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Elzur, Uri
Sent: Friday, April 01, 2016 5: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

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]<mailto:[email-masked]>>; Dave Dolson <[email-masked]<mailto:[email-masked]>>; Bottorff, Paul <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[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]<mailto:[email-masked]>>; Sunil Vallamkonda <[email-masked]<mailto:[email-masked]>>; Bottorff, Paul <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[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]<mailto:[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]<mailto:[email-masked]>>; Dave Dolson
>> <[email-masked]<mailto:[email-masked]>>; Sunil Vallamkonda <[email-masked]<mailto:[email-masked]>>;
>> [email-masked]<mailto:[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]<mailto:[email-masked]>>; Sunil
>>> Vallamkonda <[email-masked]<mailto:[email-masked]>>; Joel M. Halpern <[email-masked]<mailto:[email-masked]>>;
>>> [email-masked]<mailto:[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]<mailto:[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]<mailto:[email-masked]>>; [email-masked]<mailto:[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]<mailto:[email-masked]>
>>>>> https://www.ietf.org/mailman/listinfo/sfc
>>>>>
>>>
>>> _______________________________________________
>>> sfc mailing list
>>> [email-masked]<mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/sfc
>>>
>>> _______________________________________________
>>> sfc mailing list
>>> [email-masked]<mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/sfc
>>>

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

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 11 Jul 2016 13:09:38 -0400

I find it very hard to understand the advantage of the proposed 
framework.  I am usually of the opinion that indirection is helpful in 
solving protocol identification problems.  In this case however, I can 
not see any value in having control specify to an SF "You will find 
field X under TLV code A" using a quasi-standard X.  For things with 
standard type code, there is clearly no need for such.  For things with 
vendor defined type codes, the label X is no more useful than the vendor 
defined type code.  After all, if the meaning of X were standard, then 
there would presuambly be a standard type code assigned to it.  We have 
lots of space.

Yours,
Joel

On 7/11/16 12:49 PM, Linda Dunbar wrote:
> _https://datatracker.ietf.org/doc/draft-vallamkonda-sfc-metadata-model/_has
> the examples of metadata that may need to be passed among SFs along a
> SFP, e.g.
>
> /SF1 may at real-time attach DoS information for the next SF in
> downstream. SF1 provides the hint and it is up to the downstream SFs to
> process it or ignore it. However if a downstream SF chooses to
> processes, it needs standardized metadata data model to understand the
> hint encoded by SF1 in packets./
>
> To minimize the extra bytes added to packets in NSH, it is necessary to
> have compact encoding of the metadata carried by data packets. Achieving
> this goal will need control plane to inform the encoding mechanisms to
> SFs via out of band control channels.
>
> 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
>
> To: Joel M. Halpern <[email-masked] <mailto:[email-masked]>>;
> Dave Dolson <[email-masked] <mailto:[email-masked]>>;
> Bottorff, Paul <[email-masked] <mailto:[email-masked]>>;
> [email-masked] <mailto:[email-masked]>
> 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
>
> To: Dave Dolson <[email-masked] <mailto:[email-masked]>>;
> Sunil Vallamkonda <[email-masked] <mailto:[email-masked]>>; Bottorff,
> Paul <[email-masked] <mailto:[email-masked]>>;
> [email-masked] <mailto:[email-masked]>
> 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
>
>> To: Sunil Vallamkonda; Bottorff, Paul; Dave Dolson; [email-masked] <mailto:[email-masked]>
>>> 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
>>>
>>> To: Bottorff, Paul <[email-masked] <mailto:[email-masked]>>; Dave Dolson
>>> <[email-masked] <mailto:[email-masked]>>; Sunil Vallamkonda
> <[email-masked] <mailto:[email-masked]>>;
>>> [email-masked] <mailto:[email-masked]>
>>>> 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
>>>>
>>>> To: Joel Halpern Direct <[email-masked] <mailto:[email-masked]>>; Sunil
>>>> Vallamkonda <[email-masked] <mailto:[email-masked]>>; Joel M. Halpern
> <[email-masked] <mailto:[email-masked]>>;
>>>> [email-masked] <mailto:[email-masked]>
>>>> To: Sunil Vallamkonda; Joel M. Halpern; [email-masked] <mailto:[email-masked]>
>>>>> 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.
>>>>>
>>>>> To: Sunil Vallamkonda <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>>>>>> [email-masked] <mailto:[email-masked]>
>>>> [email-masked] <mailto:[email-masked]>
>>>> [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>

---

From: Dave Dolson <[email-masked]>
Date: Mon, 11 Jul 2016 17:24:37 +0000

Clearly metadata passed between two SFs needs to be understood by both. 
I think Joel is correct that standardization covers this case -- at
least for AVPs in MD-Type 2.

But I don't believe standardization covers the MD-Type-1 format,
since there doesn't seem to be an allocation that fits all.
Control-plane indication of "what are in slots 1..4?" seems necessary.

And another issue is that such metadata may need to pass through an 
intermediary SF that does NOT know the standardization, and may NOT
know the semantics of the metadata.

We are also attempting to provide sufficient description of the metadata
that an intermediary can avoid breaking things.
When an intermediary injects packets into a chain it is particularly
important for it to be aware of the semantics -- perhaps including
the case when packets cannot be injected.

-Dave

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Monday, July 11, 2016 1:10 PM
To: Linda Dunbar; Elzur, Uri; Sunil Vallamkonda; Dave Dolson; Bottorff, Paul; [email-masked]
Subject: Re: Examples of Metadata that need to be passed among SFs : regarding draft-vallamkonda-sfc-metadata-model-01.txt

Yours,
Joel

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 11 Jul 2016 17:26:48 +0000

Joel, 

Are you suggesting that it is better to have standard type code for each metadata? 

Linda

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Monday, July 11, 2016 12:10 PM
To: Linda Dunbar; Elzur, Uri; Sunil Vallamkonda; Dave Dolson; Bottorff, Paul; [email-masked]
Subject: Re: Examples of Metadata that need to be passed among SFs : regarding draft-vallamkonda-sfc-metadata-model-01.txt

I find it very hard to understand the advantage of the proposed framework.  I am usually of the opinion that indirection is helpful in solving protocol identification problems.  In this case however, I can not see any value in having control specify to an SF "You will find field X under TLV code A" using a quasi-standard X.  For things with standard type code, there is clearly no need for such.  For things with vendor defined type codes, the label X is no more useful than the vendor defined type code.  After all, if the meaning of X were standard, then there would presuambly be a standard type code assigned to it.  We have lots of space.

Yours,
Joel

On 7/11/16 12:49 PM, Linda Dunbar wrote:
> _https://datatracker.ietf.org/doc/draft-vallamkonda-sfc-metadata-model
> /_has the examples of metadata that may need to be passed among SFs 
> along a SFP, e.g.
>
> downstream. SF1 provides the hint and it is up to the downstream SFs 
> to process it or ignore it. However if a downstream SF chooses to 
> To minimize the extra bytes added to packets in NSH, it is necessary 
> to have compact encoding of the metadata carried by data packets. 
> Achieving this goal will need control plane to inform the encoding 
> mechanisms to SFs via out of band control channels.
>
> interoperability among vendors, in a specific example e.g. FW LB NAT 
> (or choose your favorite). Notice some proposed directions in your draft.
>
> To: Joel M. Halpern <[email-masked] 
> <mailto:[email-masked]>>; Dave Dolson <[email-masked] 
> <mailto:[email-masked]>>; Bottorff, Paul <[email-masked] 
> <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> 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.
>
> 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'
> 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
>
> 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
>
>>> 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 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
>>
>>
>> simply ignore any metadata that they do not understand.  In the 
>> common case, SFF will ignore all metadata entirely.
>>
>> 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:
>> service function.  This is hard.  I do not see how the framework 
>> helps here at all.  Is it needed?
>>
>> Yours,
>> Joel
>>
>>> 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
>>> To: Bottorff, Paul <[email-masked] 
>>> <mailto:[email-masked]>>; Dave Dolson <[email-masked] 
>>> <mailto:[email-masked]>>; Sunil Vallamkonda
>>>> 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
>>>> To: Joel Halpern Direct <[email-masked] 
>>>> <mailto:[email-masked]>>; Sunil Vallamkonda 
>>>> <[email-masked] <mailto:[email-masked]>>; Joel M. Halpern
>>>> articulated in 
>>>> https://tools.ietf.org/html/draft-penno-sfc-packet-02
>>>>> 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
>>>>>> Additionally,  interoperability and vendor support challenges 
>>>>>> need to be addressed in a scalable and adaptable way for rapid deployment.
>>>>>>
>>>>>> has been successfully submitted by Sunil Vallamkonda and posted 
>>>>>> to the IETF repository.
>>>>>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 11 Jul 2016 14:11:14 -0400

Whenever we have agreement on meaning and there being some utility, I 
would expect to see a standard code point assigned for that metadata 
usage.

This does mean that someone has to do the work to write down the meaning.

I do not expect all code points to be standardized.  But standardization 
is intended precisely to ddress inter-vendor interoperability.

Having said that, I do expect there to be cases where vendors need to 
agree on code point usage without having (yet or ever) standardized. 
For that case, they need to communicated.  I do not see hwo this 
framework helps that communication.

Yours,
Joel