Subject: [sfc] Metadata and inserted packets

From: Dave Dolson <[email-masked]>
Date: Thu, 2 Apr 2015 19:00:07 +0000

I'd like to start a thread on how service functions deal with metadata in NSH, in particular how an SF might decide what metadata should be added to a packet it injects.
(Issues I raised in Dallas.)

I'm starting from the assumption that when an SF injects a packet, it knows which service path ID and Service Index (and other NSH header fields) should be used. The semantics of these fields are well defined.

However, I'm having trouble with what metadata values should be used. My belief is that some semantics must be defined for metadata.

This question applies to MD-type 1, in which the semantics of each of the 4 Mandatory Context Headers must be known, as well as the optional fields of MD-types 1 & 2, where a potentially large set of TLV class/Type must be dealt with.

The MD-type-1 question is probably more easily dealt with by documentation, although draft-ietf-sfc-nsh-00 does not say enough. I think draft-guichard-sfc-nsh-dc-allocation-01 and draft-napper-sfc-nsh-mobility-allocation-00 could define things clearly enough.
(For example, what "Source Class" from dc-allocation should be added to injected traffic?)

Allow me to put forward some propositions for you to knock down:

1.       Meta-data representing a notion of network separation (e.g., tenant) must be standardized as such so that traffic does not cross networks.

2.       In general, meta-data must not be more specific than a transport session (e.g., TCP or UDP connection). This allows injection of metadata by cloning exemplar packets of the same flow.

3.       If meta-data is more specific than a transport session, all SFs that might encounter such meta-data must be aware of the semantics (could be configured or hard-coded)

David Dolson
Senior Software Architect, Sandvine Inc.

---

From: Sunil Vallamkonda <[email-masked]>
Date: Tue, 7 Apr 2015 18:07:22 +0000

Hello David,

To address below, the metadata would need to be adaptable and scalable across vendors as TLVs in service chains.
I'd suggest a format for TLV metadata :

-----------------------------------------------------------------------
|      Type               |     Length         |         Vendor-ID                    |
-----------------------------------------------------------------------
|   Vendor-Type       |   Vendor-Length  |   Attribute-Value  |
-----------------------------------------------------------------------

Thank you,
Sunil

From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: Thursday, April 02, 2015 12:00 PM
To: [email-masked]
Subject: [sfc] Metadata and inserted packets

David Dolson

---

From: Dave Dolson <[email-masked]>
Date: Tue, 7 Apr 2015 18:59:48 +0000

Sunil,

How would the SF know the semantics of the metadata with respect to packet injection?

Would you have an out-of-band dictionary that maps vendor/type to the information?
(E.g., "vendor/type 1001/27 is a network separation identifier")

The semantics could also be placed in-band, in the form of a fieldd.
field values:
- network separation metadata
- transport flow attribute metadata
- source IP metadata
- destination IP metadata

-Dave

From: Sunil Vallamkonda [mailto:[email-masked]]
Sent: Tuesday, April 07, 2015 2:07 PM
To: Dave Dolson; [email-masked]
Subject: RE: Metadata and inserted packets

Hello David,

Thank you,
Sunil

From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: Thursday, April 02, 2015 12:00 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [sfc] Metadata and inserted packets

David Dolson

---

From: Sunil Vallamkonda <[email-masked]>
Date: Tue, 7 Apr 2015 19:24:58 +0000

Hi David,

The vendor dictionary could be OOB from Classifier in control plane as part of provisioning.
The in-band semantics may be restrictive on metadata across vendors and TLVs, IMHO.

Thank you,
Sunil

From: Dave Dolson [mailto:[email-masked]]
Sent: Tuesday, April 07, 2015 12:00 PM
To: Sunil Vallamkonda; [email-masked]
Subject: RE: Metadata and inserted packets

Sunil,

-Dave

From: Sunil Vallamkonda [mailto:[email-masked]]
Sent: Tuesday, April 07, 2015 2:07 PM
To: Dave Dolson; [email-masked]<mailto:[email-masked]>
Subject: RE: Metadata and inserted packets

Hello David,

Thank you,
Sunil

David Dolson

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 07 Apr 2015 21:17:35 -0400

I would expect that there will need to be application configuration that 
indicates what metadata type code a given SF should use for communicate 
what piece of information.  This "type" might be a position in the fixed 
MD-1, or a TLV code in the MD-2.

I do not expect that the protocol for provisioning this to service 
functions is part of SFC, any more than all the other configuration 
information that applications need to do their job.

While I would not be surprised to eventually have a registry of 
well-known types, I do not see anyw ay to get around needing the 
configuration information for many service functions which care about 
metadata.  There is just going to be too much variability.

I hope that we do not have to put vendor IDs into the types, as the MD-2 
TLV already looks to be larger than we like.

Yours,
Joel

On 4/7/15 2:59 PM, Dave Dolson wrote:
> (E.g., “vendor/type 1001/27 is a network separation identifier”)
>
> *From:*Sunil Vallamkonda [mailto:[email-masked]]
> *Sent:* Tuesday, April 07, 2015 2:07 PM
> *To:* Dave Dolson; [email-masked]
> *Subject:* RE: Metadata and inserted packets
>
> Hello David,
>
> To address below, the metadata would need to be adaptable and scalable
> across vendors as TLVs in service chains.
>
> I’d suggest a format for TLV metadata :
>
> *From:* sfc [mailto:[email-masked]] *On Behalf Of *Dave Dolson
> *Sent:* Thursday, April 02, 2015 12:00 PM
> *To:* [email-masked] <mailto:[email-masked]>
> *Subject:* [sfc] Metadata and inserted packets
>
> I’d like to start a thread on how service functions deal with metadata
> in NSH, in particular how an SF might decide what metadata should be
> added to a packet it injects.
>
> I’m starting from the assumption that when an SF injects a packet, it
> knows which service path ID and Service Index (and other NSH header
> fields) should be used. The semantics of these fields are well defined.
>
> However, I’m having trouble with what metadata values should be used. My
> belief is that some semantics must be defined for metadata.
>
> This question applies to MD-type 1, in which the semantics of each of
> the 4 Mandatory Context Headers must be known, as well as the optional
> fields of MD-types 1 & 2, where a potentially large set of TLV
> class/Type must be dealt with.
>
> The MD-type-1 question is probably more easily dealt with by
> documentation, although draft-ietf-sfc-nsh-00 does not say enough. I
> think draft-guichard-sfc-nsh-dc-allocation-01 and
> draft-napper-sfc-nsh-mobility-allocation-00 could define things clearly
> enough.
>
> (For example, what “Source Class” from dc-allocation should be added to
> injected traffic?)
>
> 1.Meta-data representing a notion of network separation (e.g., tenant)
> must be standardized as such so that traffic does not cross networks.
>
> 2.In general, meta-data must not be more specific than a transport
> session (e.g., TCP or UDP connection). This allows injection of metadata
> by cloning exemplar packets of the same flow.
>
> 3.If meta-data is more specific than a transport session, all SFs that
> might encounter such meta-data must be aware of the semantics (could be
> configured or hard-coded)
>
> David Dolson
>
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: Nicolas BOUTHORS <[email-masked]>
Date: Mon, 13 Apr 2015 07:59:42 +0000

Hello all,

Standardization of well known metadata types has been addressed for IPFX (Netflow) in the context of IANA.
 See http://www.iana.org/assignments/ipfix/ipfix.xhtml

The IPFIX 16bit Information Element identitier field is pretty much the same as the NSH  TLV Class field.  It has the same size
and the same objective which is to identify the type of Metadata transported.

IPFIX RFC7011 describes how to take info account Entreprise extensions relying on a Field Specifier  Format (using a reserved Enterprise bit in the  16bit Information Element identifier field)

It is worth adopting the same model as:
- It is already standardized,
- It has room for extensions
- Is was designed to facilitate interoperatobility and is now widely used.
- It will facilitate SFC integration with Monitoring based system for SFC traffic (avoiding unnecessary conversions)

I propose we :
1) support the Entreprise bit in  NSH TLV Class
2) refer to See http://www.iana.org/assignments/ipfix/ipfix.xhtml for well known values

Nicolas

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]]
Sent: mercredi 8 avril 2015 03:18
To: Dave Dolson; Sunil Vallamkonda; [email-masked]
Subject: Re: [sfc] Metadata and inserted packets

I would expect that there will need to be application configuration that indicates what metadata type code a given SF should use for communicate what piece of information.  This "type" might be a position in the fixed MD-1, or a TLV code in the MD-2.

I do not expect that the protocol for provisioning this to service functions is part of SFC, any more than all the other configuration information that applications need to do their job.

While I would not be surprised to eventually have a registry of well-known types, I do not see anyw ay to get around needing the configuration information for many service functions which care about metadata.  There is just going to be too much variability.

I hope that we do not have to put vendor IDs into the types, as the MD-2 TLV already looks to be larger than we like.

Yours,
Joel

On 4/7/15 2:59 PM, Dave Dolson wrote:
> However, I’m having trouble with what metadata values should be used.
> My belief is that some semantics must be defined for metadata.
>
> draft-napper-sfc-nsh-mobility-allocation-00 could define things
> clearly enough.
>
> (For example, what “Source Class” from dc-allocation should be added
> to injected traffic?)
>
> session (e.g., TCP or UDP connection). This allows injection of
> metadata by cloning exemplar packets of the same flow.
>
> might encounter such meta-data must be aware of the semantics (could
> be configured or hard-coded)
>
> David Dolson
>

This message and any attachments (the "message") are confidential, intended solely for the addressees. If you are not the intended recipient, please notify the sender immediately by e-mail and delete this message from your system. In this case, you are not authorized to use, copy this message and/or disclose the content to any other person. E-mails are susceptible to alteration. Neither Qosmos nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified.

Ce message et toutes ses pièces jointes (ci-après le "message")sont confidentiels et établis à l'intention exclusive de ses destinataires. Si vous avez reçu ce message par erreur, merci d’en informer immédiatement son émetteur par courrier électronique et d’effacer ce message de votre système. Dans cette hypothèse, vous n’êtes pas autorisé à utiliser, copier ce message et/ou en divulguer le contenu à un tiers. Tout message électronique est susceptible d'altération. Qosmos et ses filiales déclinent toute responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 13 Apr 2015 07:04:06 -0400

Actually Nicolas, none of the IPFix information identifiers are likely 
to appear as metadata with an  SFC packet (i.e. the metadata in the NSH 
header.)  While I do expect to se a registry for some metadata (such 
registries improve interoperability), I don't see any reason to think 
that the IPFIX registry is either a good basis or a good model for the work.

Yours,
Joel