Subject: [sfc] comments on draft-quinn-nsh

From: Ron Parker <[email-masked]>
Date: Fri, 14 Feb 2014 14:23:48 +0000

Hello authors of draft-quinn-nsh.   Thanks for posting the update.     I have concerns on the metadata portion of the proposal.    I think there are some requirements that the group should work through, first, before we can pin down the actual bits and bytes.   For example, a very partial list of requirements that come to mind:

*         Registered metadata types

o   Like the official IPv4 options or the official IPv6 extension headers

*         Vendor specific metadata types

o   Using an OUI of some sort

*         Flexible length metadata

o   For example, a 64-bit subscriber ID

*         Support for both long lived (for the duration of the flow or until changed or revoked) and temporal (packet by packet) inband metadata

o   Acknowledgement scheme that long lived data no longer needs to be inserted

There was an example in Vancouver where 2 non-adjacent coordinated service functions shared a priority discard eligibility between them.   In draft-ma-sfc, there is the need to insert private correlation handles.    All of this can be happening at the same time.   The metadata capabilities need to support these types of models, and more, if SFC is really going to enable innovation in the networks.

Thanks.

    Ron

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Fri, 14 Feb 2014 16:16:21 +0000

Hi Ron,

As always, thanks for your comments.

See you in London?

On Feb 14, 2014, at 9:23 AM, Ron Parker <[email-masked]<mailto:[email-masked]>> wrote:

NSH provides an envelop, it doesn't describe or preclude your scenarios below.  Certainly, any new encap will require balancing several sets of requirements.

Both of these types can be carried via NSH if required.   The broad applicability of context data  is going to make it hard to have a widespread register.  For instance, the metadata requirements for mobility are vastly different than those for data center.   Assignment of  semantics can be handled via a common control plane.

Having said that, I suspect we'll see de-facto types of metadata per vertical/use cases.  For example, as the mobility use case draft evolve, I hope the reach consensus on the information exchanged for that use case.

Although very seductive, variable length headers have profound implication on a wide range of platforms.    Don't think of the fixed size of header of carrying all context explicitly, rather, think of the context, when needed, as providing a reference to richer data.  Using a fixed sized header to point to richer context information provides a middle road.

To me, this is addressed under the envelop category: a signaling mechanism that will be implemented via the SFC encap, there's nothing in NSH that precludes this.

Thanks.

    Ron

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