Subject: Re: [sfc] A new proposal on a flexible-length service chain header that is transport independent

From: Kevin Glavin <[email-masked]>
Date: Tue, 1 Apr 2014 18:01:38 +0000

Hi Cathy et Al.

I had a read of your draft, nice flexible use of TLV to support meta data moving forwards, I note that it takes a different approach than the NSH draft which is focused on a fixed length header.

At this early stage, I am unsure what the requirements for such a header are -   specifically in its complexity and expandability, do you have any thoughts on the subject?
Do you see a significant need for large variation in the size and complexity of the {SCH} encapsulation? Or is a fixed setup with enumeration within the fixed space adequate and potentially more efficient?

Its an interesting area and as I think as more details are fleshed out in detailing the use cases within the space, it may be possible to get some metrics to aid in understanding what is required longterm.

Thanks
Kevin

---

From: "Louis.Fourie" <[email-masked]>
Date: Tue, 1 Apr 2014 19:15:51 +0000

Kevin,
There has been discussion on the need to transport various forms of metadata
along the service chain. Several different examples have been cited, e.g., app-id, subscriber-id, etc.
This proposal  addresses the need for a flexible method of transporting that
metadata that would allow for innovation in the chaining  of different services.

-          Louis

From: sfc [mailto:[email-masked]] On Behalf Of Kevin Glavin
Sent: Tuesday, April 01, 2014 11:02 AM
To: [email-masked]
Cc: Cathy Zhang
Subject: Re: [sfc] A new proposal on a flexible-length service chain header that is transport independent

Hi Cathy et Al.

Thanks
Kevin

---

From: Kevin Glavin <[email-masked]>
Date: Tue, 1 Apr 2014 20:19:59 +0000

Thanks Louis,

>
>Several different examples have been cited, e.g., app-id, subscriber-id, etc.

It would be a worthwhile exercise to collect concrete examples of each of the types that you mentioned and categorize them in terms of size and also in terms of potential for simultaneous use.

On the size issue:
* I suspect that app id < uint32 so in the bigger picture its a non issue how its coded.
        * If we say (mobile) subscriber-id — how will people expect this to be used?, a unique u32 id is an option at one end of the spectrum while an IMEI (16digits), or an MSISDN (15 digits (I think)) is at the other end of the spectrum. With IMSI being a 64bit number that falls in the middle of the spectrum.

  Fixed encoding suits the short end of the spectrum while TLV suits the longer or variable options, how to do other examples from use cases fall in this spectrum?

On the issue of potential simultaneous use:

My understanding is that SFC is currently targeted at deployments within a single administrative domain, so the encoded tag only has context within that domain. If it only has context within the domain, then you could argue that the context (T) is not providing any information and if the id can be formatted into a fixed length ( L) then all that is interesting is the Value (V) — taking the position that within an administrative domain a single value namespace with fixed context is all that is needed.

To further my questioning, is there a expectation that there will be multiple independent uses within the same domain, if there is then unique tag id is important as the same value has the potential to appear in both uses within the same administrative domain e.g IMEI and MSISDN being used for subscriber-id interchangeably.

Kevin

---

From: "Louis.Fourie" <[email-masked]>
Date: Fri, 4 Apr 2014 22:00:57 +0000

Kevin,
The proposed TLV format for the in-band transport of metadata for service chaining
is motivated by these reasons:

-          A service domain will be multi-vendor and there is a need for service functions
offered by different vendors to interoperate in such an environment. The optional OUI
in the TLV allows for this.

-          There is a need to identify each item of metadata so that service functions can extract
relevant metadata items from the service chain header.

-          The length field allows service functions that do not recognize a metadata TLV to
skip over that TLV.

-          The usage of TLVs is optional, so that service chains can be created using the
SCH header without any TLVs.

Examples of types of metadata can be found in section 2.2 of the 'Metadata Considerations' I-D:

Examples of such metadata include:

   o  A Subscriber-ID, or more accurately, an Accounting-ID which maps
     traffic flows to a unique identifier used for accounting and
      billing purposes.

   o  A Service-Profile-ID and/or Service-Profile-Parameters which
      identify the service which the Service Functions must apply to
      the traffic flow.  This is discussed in more detail in section
      2.4.

Others are cited in section 2.4 of the 'SFC Use Cases in Mobile Networks' I-D:

   Typical metadata and their sources are:

   UE:  terminal type (e.g., HTC one); IMSI (country, carrier, user);

   GTP tunnel endpoint:  eNB-Identifier; time;

   PCRF:  subscriber info; APN (service name); QoS; policy rules.

These are typically of variable length.

-          Louis

From: Kevin Glavin [mailto:[email-masked]]
Sent: Tuesday, April 01, 2014 1:20 PM
To: Louis.Fourie; [email-masked]
Cc: Cathy Zhang
Subject: Re: [sfc] A new proposal on a flexible-length service chain header that is transport independent

Thanks Louis,

On the size issue:
* I suspect that app id < uint32 so in the bigger picture its a non issue how its coded.
        * If we say (mobile) subscriber-id - how will people expect this to be used?, a unique u32 id is an option at one end of the spectrum while an IMEI (16digits), or an MSISDN (15 digits (I think)) is at the other end of the spectrum. With IMSI being a 64bit number that falls in the middle of the spectrum.

My understanding is that SFC is currently targeted at deployments within a single administrative domain, so the encoded tag only has context within that domain. If it only has context within the domain, then you could argue that the context (T) is not providing any information and if the id can be formatted into a fixed length ( L) then all that is interesting is the Value (V) - taking the position that within an administrative domain a single value namespace with fixed context is all that is needed.

Kevin

---

From: Kevin Glavin <[email-masked]>
Date: Fri, 4 Apr 2014 22:46:41 +0000

Louis,

I have to agree that all these are strong reasons for a TLV approach.

Kevin

From: "Louis.Fourie" <[email-masked]<mailto:[email-masked]>>
Date: Friday, April 4, 2014 3:00 PM
To: Kevin Glavin <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Cathy Zhang <[email-masked]<mailto:[email-masked]>>
Subject: RE: [sfc] A new proposal on a flexible-length service chain header that is transport independent

Kevin,

Examples of types of metadata can be found in section 2.2 of the ‘Metadata Considerations’ I-D:

Others are cited in section 2.4 of the ‘SFC Use Cases in Mobile Networks’ I-D:

-          Louis