Subject: [spring] 答复: [sfc] SFC encapsulation chain ID

From: Xuxiaohu <[email-masked]>
Date: Thu, 20 Mar 2014 04:01:27 +0000

发件人: sfc [mailto:[email-masked]] 代表 Changcheng Huang
发送时间: 2014年3月19日 22:23
收件人: Paul Quinn (paulq)
抄送: David Allan I; Sumandra Majee; [email-masked]
主题: Re: [sfc] SFC encapsulation chain ID

Definite #2. Carrying path list in header is a heavy overhead which should be avoided.

[Xiaohu] Whether the overhead of carrying explicit path information (i.e., an ordered list of nodes) is heavy or not,  supporters for the SR mechanism, especially those for IPv6-SR mechanism (http://tools.ietf.org/html/draft-martin-spring-segment-routing-ipv6-use-cases-00) may have different opinions☺

Best regards,
Xiaohu

Chang

------------
Changcheng Huang

On Mar 19, 2014, at 5:44 AM, "Paul Quinn (paulq)" <[email-masked]<mailto:[email-masked]>> wrote:
Hi Sumandra,

I lean towards #2: essentially encoding the information into a simple ID, rather than trying to create a variable length stack.  The encoding method is much simpler for SFs to process, and as you point out update and modify.

Paul

On Mar 19, 2014, at 3:40 AM, Sumandra Majee <[email-masked]<mailto:[email-masked]>> wrote:

<<Trimmed the TO list to avoid the msg being held again>>

I see two ways to carry the path information.

  1.  Explicit ordered list, something like FW-A :: TCP-OPT :: LB :: VideoOPT :: CGNAT.   There are two issues with this approach, first the length of graph is variable.  Also it implies bidirectional symmetry. It is often required but should not be mandatory.  Secondly changing this path/graph in at SF can be cumbersome.
  2.  Let the Control plane distribute the chainID <—> graph mapping. In this case each SF would have mapping of given a chainID what is my next hop. The chainID itself could be fixed size element. A SF can select a different path by changing the chaiID parameter.

Regards
Sumandra

From: Cathy Zhang <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, March 18, 2014 at 10:13 AM
To: "Reinaldo Penno (repenno)" <[email-masked]<mailto:[email-masked]>>, "Louis.Fourie" <[email-masked]<mailto:[email-masked]>>, "Paul Quinn (paulq)" <[email-masked]<mailto:[email-masked]>>, David Allan I <[email-masked]<mailto:[email-masked]>>
Cc: Nicolas BOUTHORS <[email-masked]<mailto:[email-masked]>>, Xuxiaohu <[email-masked]<mailto:[email-masked]>>, Changcheng Huang <[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]>>
Subject: Re: [sfc] SFC encapsulation chain ID

Hi Reinaldo,

So the chain ID is actually the path ID which represents an ordered set of service function instances.
I think we should add an explicit definition of “service instance”. What do you think?

Thanks,
Cathy

From: sfc [mailto:[email-masked]] On Behalf Of Reinaldo Penno (repenno)
Sent: Tuesday, March 18, 2014 11:03 AM
To: Louis.Fourie; Paul Quinn (paulq); David Allan I
Cc: Nicolas BOUTHORS; Xuxiaohu; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Changcheng Huang
Subject: Re: [sfc] SFC encapsulation chain ID

A Service Chain just defines which type of service and their order.

A service path defines the actual service instance, say, firewall1.home, nat2, dpi-sic, etc.

From: "Louis.Fourie" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, March 18, 2014 at 10:55 AM
To: "Paul Quinn (paulq)" <[email-masked]<mailto:[email-masked]>>, David Allan I <[email-masked]<mailto:[email-masked]>>
Cc: Nicolas BOUTHORS <[email-masked]<mailto:[email-masked]>>, Xuxiaohu <[email-masked]<mailto:[email-masked]>>, Changcheng Huang <[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]>>
Subject: Re: [sfc] SFC encapsulation chain ID

Paul,
   Can you clarify the difference between service chain and service path. Given that a service chain is composed
of several service functions SF1, SF2, .. SFn how would a service path differ from that service chain?

-          Louis

From: sfc [mailto:[email-masked]] On Behalf Of Paul Quinn (paulq)
Sent: Tuesday, March 18, 2014 10:26 AM
To: David Allan I
Cc: Nicolas BOUTHORS; Xuxiaohu; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Changcheng Huang
Subject: Re: [sfc] SFC encapsulation chain ID

Hi Dave,

Chain ID should really be path ID since there can be many paths for a given chain.  Using that definition, we avoid the overload and reap the gain alluded to below.

Paul

On Mar 18, 2014, at 12:14 PM, David Allan I <[email-masked]<mailto:[email-masked]>> wrote:

Well the question de jour is “does a chain ID define a class or an instance”…. If it defines an class we also need instance information, if it is currently overloaded to define class and instance IMO we have a problem….

Dave

From: sfc [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Changcheng Huang
Sent: Tuesday, March 18, 2014 7:43 AM
To: Nicolas BOUTHORS
Cc: Xuxiaohu; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] 答复: SFC encapsulation chain ID

Good points. I believe explicit chain ID should be mandatory. The overhead is very little. It helps simplify processing and steering significantly. The gain is huge.

Chang

------------
Changcheng Huang

On Mar 18, 2014, at 1:53 AM, Nicolas BOUTHORS <[email-masked]<mailto:[email-masked]>> wrote:
I think that keeping the Service Path Layer transport independent should remain an objective for SFC.  Such a separation of concerns is a sound architectural principle that help keep things simple in practice.

On the question of  Service Path, we have a discussion on whether we need some kind of explicit identifier or
could we rely on mapping on some underlay network protocol fields.

May be a PRO/CON table could help focus the group decision on that matter

  *   Visibility (tracing)
  *   Forwarding graph structure impact/limitations
  *   Reconfiguration speed

     *   LBS / scale out impact
     *   Node bypass (e.g; maintenance)

  *   underlay network/transport layers support
  *   Header space impact
  *   Multi tenant support impact
  *   SFC on flat (e.g optical L2 for Data Centers) network
  *   Underlay network administration impact

Personally I think that having an explicit chain identifier (e.g. Service Path/Service Index) is clear (management and control) and not expensive (header space). The drawback being some impact on the simplicity to add/remove elements in a chain dynamically.

Tag switching (as MPLS)  allows to manage tags per service nodes, leading to more versatile and diverse graphs

Nicolas
________________________________
From: Xuxiaohu [[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, March 18, 2014 5:04 AM
To: Jerome Moisand; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [sfc] 答复: SFC encapsulation chain ID
I like the idea of separating the Service Function Layer and the Service Path Layer, as proposed in draft-rijsman-sfc-metadata-considerations. The role of the Service Path Layer is just to steer the traffic along a particular chain of service nodes which can be implemented by existing tools for source routing, such as segment routing. As such, it’s not necessary to try to keep the Service Path Layer transport-independent and contain it in the SFC header.

Best regards,
Xiaohu

发件人: sfc [mailto:[email-masked]] 代表 Jerome Moisand
发送时间: 2014年3月18日 1:03
收件人: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
主题: Re: [sfc] SFC encapsulation chain ID

This (lengthy and very lively) thread started from draft-rijsman-sfc-metadata-considerations (which I co-authored).

In section 4.8, we made a clear distinction between a service path layer (steering packets hop by hop along the chain) and a service function layer (convey metadata information of interest to SFs). Terminology aside, it seems that such layered view was agreed upon by many people on the mailing list.

Now this certainly does beg the question of solving BOTH problems with the same (packet) encapsulation mechanism. Notably when observing that many use cases could be satisfied without SF-level metadata, or by using more out-of-band ways to convey such SF metadata. And also when observing that inband marking (e.g. packet headers) comes with various pros & cons (some of the issues being identified in the draft, e.g. sections 4.1 and 4.2).

I do agree with Maria. We may want to explore other options for addressing the needs of the service path layer that do not require an explicit chain-id of sorts.

In the draft, we concluded by stating “A productive path forward could be to divide and conquer: to clearly separate the problem of Service Function Path topology from the   problem of [conveying SF] metadata”. I do believe we should explore such separation principle further.

From: sfc [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Friday, March 14, 2014 5:50 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] SFC encapsulation chain ID

I would imagine that if we made the Chain ID field in the header be optional, yet still required a header and still required that some indication of the chain be carried somewhere in the packet (mpls label or vlan or whatever), that the implementation would become overly complicated.  To do so would be using SFC simply as a mechanism to carry meta data and not at all for service chaining, which sounds counter intuitive to me.

Maria,
So, you are saying that you want to use SFC to carry around metadata, but not for actual service chaining because you already have a way to implement service chaining outside of SFC?  Maybe I'm not following, but it seems to me that if you were to upgrade your network to support SFC that you would change from using your existing mechanism and start using SFC, which is meant to provide support for service functions that are not SFC aware.  There are a number of us who have implemented, in one way or another, some sort of service chaining, but I (I can at least speak for myself) am looking to SFC not to enhance my current implementation, but to replace it with something better while still maintaining my core (non service function) infrastructure.
________________________________
From: [email-masked]<[email-masked]<mailto:[email-masked][email-masked]>>
To: Ron Parker<[email-masked]<mailto:[email-masked]>>,Jim Guichard (jguichar)<[email-masked]<mailto:[email-masked]>>,Joel M. Halpern<[email-masked]<mailto:[email-masked]>>
cc: [email-masked]<[email-masked]<mailto:[email-masked][email-masked]>>
Sent: Friday, March 14, 2014
Subject: Re: [sfc] SFC encapsulation chain ID

+1 the idea is interoperability.

On 3/14/14 12:55 PM, "Ron Parker" <[email-masked]<mailto:[email-masked]>> wrote:

>Thanks, Jim.
>
>Remember that we have said many times that the SFC service header is
>transport independent.   Just because the chain id could be carried in
>some form or another with some particular transport doesn't mean that it
>could be universally conveyed.    By making and keeping the SFC service
>header transport independent makes it more applicable in more
>environments and more likely to get adopted broadly.
>
>   Ron
>
>
>-----Original Message-----
>From: Jim Guichard (jguichar) [mailto:[email-masked]]
>Sent: Friday, March 14, 2014 3:52 PM
>To: Joel M. Halpern; Ron Parker
>Cc: [email-masked]<mailto:[email-masked]>
>Subject: SFC encapsulation chain ID
>
>Hi Joel,
>
>Perhaps but I would point out that the base SFC header could have a lot
>more information than just the chain ID; I would also point out that the
>devil is in the details and saying "well, I can just use an MPLS label"
>hides much of the complexity of actually doing that.
>
>On 3/14/14, 2:35 PM, "Joel M. Halpern" <[email-masked]<mailto:[email-masked]>> wrote:
>
>>If the transport header carries enough information for identifying the
>>sequence (VLAN tag or MPLS label can both do the job), then arguably
>>the global chain ID is redundant. I can live with carrying it anyway
>>either if I have metadata to carry, or if I need the chain ID for some
>>purpose.
>> After all, some folks seem to want to use that for the forwarding
>>decisions.
>>
>>Yours,
>>Joel
>>
>>On 3/14/14, 2:28 PM, Ron Parker wrote:
>>> The chain ID is the label that defines the sequence of service
>>>functions that must be visited.   It can be thought of as a handle for a
>>>stack of must-visit network locations.   I don't see how this can be
>>>anything but mandatory.
>>>
>>>     Ron
>>>
>>>
>>> -----Original Message-----
>>> From: sfc [mailto:[email-masked]] On Behalf Of Surendra Kumar
>>>(smkumar)
>>> Sent: Friday, March 14, 2014 1:46 PM
>>> To: Joel M. Halpern; NAPIERALA, MARIA H
>>> Cc: [email-masked]<mailto:[email-masked]>
>>> Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations
>>>
>>> [Trimmed the recipient list - needs approval otherwise]
>>>
>>> Completely agree here.
>>>
>>> SFC does not prevent VLAN stitching and one can continue to do that.
>>>While at the same time SFC can include VLAN stitching to support
>>>legacy SFs in the same chain that includes SFC aware SFs. Even legacy
>>>SFs benefit from chain identification and hence can be shared across
>>>different service chains.
>>>
>>> Surendra.
>>>
>>>
>>>
>>> On 3/14/14 10:26 AM, "Joel M. Halpern" <[email-masked]<mailto:[email-masked]>> wrote:
>>>
>>>> My own inclination is to observe that if you don't need explicit
>>>> chain identification and you don't need metadata, you can just omit
>>>> the sfc/nsh header. Still do service chaining, just no extra header.
>>>>
>>>> If we are going to have the header, it seems to me that the chain
>>>>identification field is very useful, and low cost once we have the
>>>>header.
>>>>
>>>> Yours,
>>>> Joel
>>>>
>>>> On 3/14/14, 1:00 PM, NAPIERALA, MARIA H wrote:
>>>>> Explicit chain identification should be made optional. I believe it
>>>>> was discussed few months ago on this mailing list.
>>>>>
>>>>> Maria
>>>>>
>>>>> *From:*sfc [mailto:[email-masked]] *On Behalf Of *Jmh.direct
>>>>> *Sent:* Thursday, March 13, 2014 12:12 PM
>>>>> *To:* [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
>>>>> [email-masked]<mailto:[email-masked]>
>>>>> *Cc:* [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]>
>>>>> *Subject:* Re: [sfc] draft-rijsman-sfc-metadata-considerations
>>>>> *Importance:* Low
>>>>>
>>>>> Assuming I understand you properly Ken, I disagree.
>>>>>
>>>>> For example, by using separate terms I can easily discuss the fact
>>>>> that certain kinds of data (chain identification) only need to be
>>>>> adjust by a few apps in rare cases. And that data is not beeded
>>>>> by the applications.
>>>>>
>>>>> Unless you would like to consider the chain identification as being
>>>>> optional?
>>>>>
>>>>> Yours,
>>>>>
>>>>> Joel
>>>>>
>>>>>
>>>>>
>>>>> Sent from my Samsung smartphone on AT&T
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -------- Original message --------
>>>>> Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations
>>>>> From: "Ken Gray (kegray)" <[email-masked]<mailto:[email-masked]>
>>>>><mailto:[email-masked]>>
>>>>> To: Lucy yong <[email-masked]<mailto:[email-masked]>
>>>>><mailto:[email-masked]>>,"Surendra<mailto:[email-masked]%3e%3e,%22Surendra> Kumar (smkumar)"
>>>>> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>,"Jim<mailto:[email-masked]%3e%3e,%22Jim> Guichard
>>>>>(jguichar)"
>>>>> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>
>>>>> CC: Nicolas BOUTHORS <[email-masked]<mailto:[email-masked]>
>>>>><mailto:[email-masked]>>,sfc<mailto:[email-masked]%3e%3e,sfc> <[email-masked]<mailto:[email-masked]>
>>>>><mailto:[email-masked]>>,Jamal<mailto:[email-masked]%3e%3e,Jamal> Hadi Salim <[email-masked]<mailto:[email-masked]>
>>>>><mailto:[email-masked]>>,Ron<mailto:[email-masked]%3e%3e,Ron> Parker
>>>>><[email-masked]<mailto:[email-masked]>
>>>>> <mailto:[email-masked]>>,"[email-masked]<mailto:[email-masked]%3e%3e,[email-masked]>
>>>>> <mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>
>>>>><mailto:[email-masked]>>,"Joel<mailto:[email-masked]%3e%3e,%22Joel> M. Halpern"
>>>>><[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>
>>>>>
>>>>> The word "metadata" is a purposely ambiguous term "data that
>>>>> provides information about other data". It is used to avoid THIS
>>>>>discussion.
>>>>>
>>>>> For example, I propose we define "tequila metadata" because,
>>>>> frankly, I will need to order a triple-shot if we keep attempting
>>>>> to define something that, by definition, is ambiguous. I'd like
>>>>> my bartender to understand me specifically when I say "I need a
>>>>>shot".
>>>>>
>>>>> On 3/13/14 7:49 AM, "Lucy yong" <[email-masked]<mailto:[email-masked]>
>>>>> <mailto:[email-masked]>> wrote:
>>>>>
>>>>>   >Snip..
>>>>>   >SK> Just copying from the PS:
>>>>>   >--
>>>>>   >Data plane metadata provides the ability to exchange information
>>>>>between
>>>>>   >the network and service functions, between service functions,
>>>>>and service
>>>>>   >functions and the network.
>>>>>   >
>>>>>   >--
>>>>>   >It is a lucid definition. We are unnecessarily making the word
>>>>>"network"
>>>>>   >controversial, IMO.
>>>>>   >
>>>>>   >[Lucy] This is my point. "The network" is too general here,
>>>>>which brings
>>>>>   >metadata great power to do many things. This is why people
>>>>>invent ideas
>>>>>   >here, which causes a lot of debates on metadata usage potentials.
>>>>> We
>>>>>   >should not spend a lot of times on that debates and judge which
>>>>>usage is
>>>>>   >valuable or not. Thus, for the SFC work, it will be helpful if
>>>>>we can
>>>>>   >narrow down a bit. Joel makes explicitly two cases, which is
>>>>>helpful to
>>>>>   >develop use cases for each case. I would like to see that the
>>>>>problem
>>>>>   >statement can be more specific on metadata definition, which may
>>>>>be
>>>>>   >helpful in less focusing on it and moving forward.
>>>>>   >
>>>>>   >Lucy
>>>>>   >
>>>>>   >Surendra.
>>>>>   >
>>>>>   >
>>>>>   >>
>>>>>   >>Thanks,
>>>>>   >>Lucy
>>>>>   >>
>>>>>   >>-----Original Message-----
>>>>>   >>From: Jim Guichard (jguichar) [mailto:[email-masked]]
>>>>>   >>Sent: Wednesday, March 12, 2014 4:38 PM
>>>>>   >>To: Lucy yong
>>>>>   >>Cc: Joel M. Halpern; Nicolas BOUTHORS; Ron Parker;
>>>>>   >>[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>; sfc; Jamal
>>>>>Hadi Salim
>>>>>   >>Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations
>>>>>   >>
>>>>>   >>Hi Lucy,
>>>>>   >>
>>>>>   >>No. I am simply saying we should not overcomplicate the problem
>>>>>   >>statement with text that adds little to no value in my opinion.
>>>>> Whether
>>>>>   >>we call it metadata, or context, has no bearing on the fact
>>>>>that the
>>>>>   >>problem statement already clearly states we need to be able to
>>>>>pass
>>>>>   >>information between SF¹s and between the network & SF¹s.
>>>>>   >>
>>>>>   >>
>>>>>   >>On 3/12/14, 5:13 PM, "Lucy yong" <[email-masked]<mailto:[email-masked]>
>>>>><mailto:[email-masked]>> wrote:
>>>>>   >>
>>>>>   >>>
>>>>>   >>>Hi Jim,
>>>>>   >>>
>>>>>   >>>I for one don't agree and think we are over complicating what
>>>>>should
>>>>>   >>>be straightforward. The SFC encapsulation should enable two
>>>>>things:
>>>>>   >>>
>>>>>   >>>1. Steering of selected flows through a service chain; this is
>>>>>the
>>>>>   >>>service function path.
>>>>>   >>>2. Passing of context associated with a given flow within said
>>>>>service
>>>>>   >>>function path. This context information may be consumed by a
>>>>>SF (an
>>>>>   >>>application ID is an example) or may be consumed by the
>>>>>forwarding
>>>>>   >>>elements (a vrf-ID is an example).
>>>>>   >>>[Lucy] Do you call the context as metadata or not? Do we have
>>>>>another
>>>>>   >>>term here beside SFC header and metadata. I see that you don't
>>>>>want to
>>>>>   >>>separate what is consumed by SF and what is consumed by the
>>>>>forwarding
>>>>>   >>>elements.
>>>>>   >>>
>>>>>   >>>Lucy
>>>>>   >>>
>>>>>   >>>Sent from my iPhone
>>>>>   >>>
>>>>>   >>>> On Mar 12, 2014, at 4:16 PM, "Lucy yong"
>>>>><[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>>>>>   >>>>
>>>>>   >>>> Great. Then we may consider two special metadata definitions
>>>>>in the
>>>>>   >>>>problem statement so we can all use the same definitions.
>>>>>Here is my
>>>>>   >>>>suggested text and like to hear you and other's input and
>>>>>suggestions.
>>>>>   >>>>
>>>>>   >>>> Dataplane Metadata: Data plane metadata provides the ability
>>>>>to
>>>>>   >>>>exchange information between the elements in a service function
>>>>>   >>>>chaining. In this context, there are two types of data plane
>>>>>metadata.
>>>>>   >>>>
>>>>>   >>>> Service Function Metadata: the information exchanged between
>>>>>   >>>>classifier and service functions, between service functions to
>>>>>   >>>>facilitate service functions on the packet treatment.
>>>>>   >>>>
>>>>>   >>>> Steering Metadata: the information from service functions to a
>>>>>   >>>>classifier or service node for traffic forwarding purpose.
>>>>>   >>>>
>>>>>   >>>> -end
>>>>>   >>>>
>>>>>   >>>> Lucy
>>>>>   >>>>
>>>>>   >>>>
>>>>>   >>>> -----Original Message-----
>>>>>   >>>> From: Joel M. Halpern [mailto:[email-masked]]
>>>>>   >>>> Sent: Wednesday, March 12, 2014 2:35 PM
>>>>>   >>>> To: Lucy yong; Nicolas BOUTHORS; Ron Parker
>>>>>   >>>> Cc: Jim Guichard (jguichar); [email-masked]<mailto:[email-masked]>
>>>>><mailto:[email-masked]>; sfc; Jamal Hadi
>>>>>   >>>> Salim
>>>>>   >>>> Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations
>>>>>   >>>>
>>>>>   >>>> Yes, I am trying to consistently distinguish those two cases
>>>>>when
>>>>>   >>>>talking about the information carried with packets in service
>>>>>chains.
>>>>>   >>>>
>>>>>   >>>> Yours,
>>>>>   >>>> Joel
>>>>>   >>>>
>>>>>   >>>>> On 3/12/14, 3:13 PM, Lucy yong wrote:
>>>>>   >>>>> Joel, See below. -----Original Message----- From: sfc
>>>>>   >>>>> [mailto:[email-masked]] On Behalf Of Joel M. Halpern
>>>>>Sent:
>>>>>   >>>>> Wednesday, March 12, 2014 2:02 PM To: Lucy yong; Nicolas
>>>>>BOUTHORS;
>>>>>   >>>>> Ron Parker Cc: Jim Guichard (jguichar);
>>>>>[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>; sfc;
>>>>>   >>>>> Jamal Hadi Salim Subject: Re: [sfc]
>>>>>   >>>>> draft-rijsman-sfc-metadata-considerations
>>>>>   >>>>>
>>>>>   >>>>> I was trying to word it carefully not to focus on who puts
>>>>>the
>>>>>   >>>>> information in, but only on who consumes the information.
>>>>>   >>>>> Information for service functions may come from the ingress
>>>>>   >>>>> classifier or from other service functions. [Lucy] this is
>>>>>the one
>>>>>   >>>>> case using metadata in your view. Information for the
>>>>>forwarding
>>>>>   >>>>> will generally come from the ingress classifier, but in
>>>>>special
>>>>>   >>>>> cases may be provided by service functions. (I keep
>>>>>wanting to get
>>>>>   >>>>> rid of those special cases, but so far there seem to be
>>>>>just enough
>>>>>   >>>>> of them to warrant covering in the solution. And more
>>>>>importantly,
>>>>>   >>>>> significant support for it in the working group.) [Lucy]
>>>>>This is
>>>>>   >>>>> the second case using metadata in your view (but you don't
>>>>>like it).
>>>>>   >>>>>
>>>>>   >>>>> And you suggest distinguishing these two cases when
>>>>>discussing
>>>>>   >>>>> about metadata usage. Is that right understanding?
>>>>>   >>>>>
>>>>>   >>>>> Lucy
>>>>>   >>>>>
>>>>>   >>>>> Yours, Joel
>>>>>   >>>>>
>>>>>   >>>>>> On 3/12/14, 2:33 PM, Lucy yong wrote:
>>>>>   >>>>>> Joel, I interpret that you suggests that distinguish the
>>>>>exchange
>>>>>   >>>>>> information data plane carried between service functions
>>>>>and the
>>>>>   >>>>>> exchange information data plane carried from a service
>>>>>function to
>>>>>   >>>>>> a service node. Is this right understanding? Lucy
>>>>>   >>>>>>
>>>>>   >>>>>> -----Original Message----- From: Joel M. Halpern
>>>>>   >>>>>> [mailto:[email-masked]] Sent: Wednesday, March 12,
>>>>>2014
>>>>> 1:19
>>>>>   >>>>>> PM
>>>>>   >>>>>> To: Lucy yong; Nicolas BOUTHORS; Ron Parker Cc: Jim Guichard
>>>>>   >>>>>> (jguichar); [email-masked]<mailto:[email-masked]>
>>>>><mailto:[email-masked]>; sfc; Jamal Hadi Salim Subject:
>>>>>   >>>>>> Re: [sfc] draft-rijsman-sfc-metadata-considerations
>>>>>   >>>>>>
>>>>>   >>>>>> My inclination would be to tune that definition to
>>>>>distinguish
>>>>>   >>>>>> between dataplane carried information intended for use by
>>>>>service
>>>>>   >>>>>> funcitons (whatever the origin), and dataplane carried
>>>>>information
>>>>>   >>>>>> intended for dataplane forwarding components.
>>>>>   >>>>>>
>>>>>   >>>>>> Yours, Joel
>>>>>   >>>>>>
>>>>>   >>>>>>
>>>>>   >>>>>>> Hi Joel,
>>>>>   >>>>>>>
>>>>>   >>>>>>> I agree that we need using the same definition for a
>>>>>term, but
>>>>>   >>>>>>> disagree that the metadata definition here is a set of
>>>>>   >>>>>>> information put in the SFC header. This may be too narrow
>>>>>or lead
>>>>>   >>>>>>> to a particular solution. I am fine with this definition
>>>>>in the
>>>>>   >>>>>>> problem statement w/ minor tweak (suggested on mailing
>>>>>list).
>>>>>   >>>>>>>
>>>>>   >>>>>>> Dataplane Metadata: Data plane metadata provides the
>>>>>ability to
>>>>>   >>>>>>> exchange information between the classifiers and service
>>>>>   >>>>>>> functions, between service functions, and service
>>>>>functions and
>>>>>   >>>>>>> the
>>>>>   >>>>>>> classifiers|service nodes.
>>>>>   >>>>>>>
>>>>>   >>>>>>> There may be a solution that a service function passes
>>>>>some
>>>>>
>>>>>   >>>>>>> information to attached service node without using SFC
>>>>>header.
>>>>>   >>>>>>>
>>>>>   >>>>>>> Thanks, Lucy
>>>>>   >>>>>>>
>>>>>   >>>>>>>
>>>>>   >>>>>>> -----Original Message----- From: Joel Halpern Direct
>>>>>   >>>>>>> [mailto:[email-masked]] Sent: Wednesday,
>>>>>March 12,
>>>>>   >>>>>>> 2014 12:25 PM To: Lucy yong; Joel M. Halpern; Nicolas
>>>>>BOUTHORS;
>>>>>   >>>>>>> Ron Parker Cc: Jim Guichard (jguichar);
>>>>>[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>;
>>>>>   >>>>>>> sfc; Jamal Hadi Salim Subject: Re: [sfc]
>>>>>   >>>>>>> draft-rijsman-sfc-metadata-considerations
>>>>>   >>>>>>>
>>>>>   >>>>>>> Lucy, you say "the metadata term means ..." The
>>>>>definition you
>>>>>   >>>>>>> then provide is a definition of the set of information we
>>>>>are
>>>>>   >>>>>>> proposing that we put in the SFC header. I, and others,
>>>>>have
>>>>>   >>>>>>> been using the term metadata more narrowly. We can use
>>>>>whatever
>>>>>   >>>>>>> definition we want. But we do need to agree on the
>>>>>definition.
>>>>>   >>>>>>> For the purposes of the WG, it seems much more useful to
>>>>>use the
>>>>>   >>>>>>> term metadata for the narrower description.
>>>>>   >>>>>>>
>>>>>   >>>>>>> Yours, Joel
>>>>>   >>>>>>>
>>>>>   >>>>>>>> On 3/12/14, 1:19 PM, Lucy yong wrote:
>>>>>   >>>>>>>> Hi Joel,
>>>>>   >>>>>>>>
>>>>>   >>>>>>>> I agree. We need to differentiate the metadata used by
>>>>>service
>>>>>   >>>>>>>>function and SFC header. The metadata term means carrying
>>>>>some
>>>>>   >>>>>>>>states along with the packet. IMO: SFC header is a kind of
>>>>>   >>>>>>>>metadata carried on packet for next service node to use.
>>>>>In the
>>>>>   >>>>>>>>context of SFC, we have term for SFC header and the
>>>>>metadata that
>>>>>   >>>>>>>>was carried between service functions, or between service
>>>>>   >>>>>>>>functions and classifiers/service nodes, which is what
>>>>>the draft
>>>>>   >>>>>>>>focus.
>>>>>   >>>>>>>>
>>>>>   >>>>>>>> Thanks, Lucy
>>>>>   >>>>>>>>
>>>>>   >>>>>>>>
>>>>>   >>>>>>>>
>>>>>   >>>>>>>>
>>>>>   >>>>>>>>
>>>>>   >>>>>>>> -----Original Message----- From: Joel M. Halpern
>>>>>   >>>>>>>> [mailto:[email-masked]] Sent: Wednesday, March 12,
>>>>> 2014
>>>>>   >>>>>>>> 11:18 AM To: Lucy yong; Nicolas BOUTHORS; Ron Parker Cc:
>>>>> Jim
>>>>>   >>>>>>>> Guichard (jguichar); [email-masked]<mailto:[email-masked]>
>>>>><mailto:[email-masked]>; sfc; Jamal Hadi Salim
>>>>>   >>>>>>>> Subject: Re: [sfc]
>>>>> draft-rijsman-sfc-metadata-considerations
>>>>>   >>>>>>>>
>>>>>   >>>>>>>> I think it is important to keep a strong distinction
>>>>>between
>>>>>   >>>>>>>> metadata (which is for use by applications) and the
>>>>>service
>>>>>   >>>>>>>> chaining information in the base service chain header,
>>>>>which is
>>>>>   >>>>>>>> for use by the service chain support mechanisms.
>>>>>   >>>>>>>>
>>>>>   >>>>>>>> Yours, Joel
>>>>>   >>>>>>>>
>>>>>   >>>>>>>>> On 3/12/14, 10:42 AM, Lucy yong wrote:
>>>>>   >>>>>>>>> Fully agree with Joe.
>>>>>   >>>>>>>>>
>>>>>   >>>>>>>>> We should not require a fix length for in-band metadata
>>>>>but
>>>>>   >>>>>>>>> also not leave it for freely usage. In fact, when a
>>>>>service
>>>>>   >>>>>>>>> node inserts SFC header on a (encapsulated) packet and
>>>>>send to
>>>>>   >>>>>>>>> next service node, SFC header itself can be seen as a
>>>>>metadata.
>>>>>   >>>>>>>>>
>>>>>   >>>>>>>>> Lucy
>>>>>   >>>>>>>>>
>>>>>   >>>>>>>>> -----Original Message----- From: sfc
>>>>>   >>>>>>>>> [mailto:[email-masked]] On Behalf Of Joel M.
>>>>>Halpern
>>>>>   >>>>>>>>> Sent: Wednesday, March 12, 2014 9:21 AM To: Nicolas
>>>>>BOUTHORS;
>>>>>   >>>>>>>>> Ron Parker Cc: Jim Guichard (jguichar);
>>>>>[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>;
>>>>>   >>>>>>>>> sfc; Jamal Hadi Salim Subject: Re: [sfc]
>>>>>   >>>>>>>>> draft-rijsman-sfc-metadata-considerations
>>>>>   >>>>>>>>>
>>>>>   >>>>>>>>> For in-band metadata, the API for access can easily be
>>>>>   >>>>>>>>> synchronous. Out of band metadata needs different
>>>>>handling.
>>>>>   >>>>>>>>> There are many cases where out-of-band metadata is
>>>>>useful and
>>>>>   >>>>>>>>> appropriate. But they do not cover all needs by any
>>>>>stretch.
>>>>>   >>>>>>>>>
>>>>>   >>>>>>>>> Even if each piece of in-band metadata is of fixed
>>>>>length,
>>>>>   >>>>>>>>> there are many different kinds of metatype. Trying to
>>>>>say
>>>>>   >>>>>>>>> "there will be exactly four pieces, and they will be of
>>>>>types
>>>>>   >>>>>>>>> t1, t2, t3, and t4" is simply too specific for even 80%
>>>>>of the
>>>>>   >>>>>>>>>needs.
>>>>>   >>>>>>>>>
>>>>>   >>>>>>>>> Yours, Joel
>>>>>   >>>>>>>>>
>>>>>   >>>>>>>>>> On 3/12/14, 8:52 AM, Nicolas BOUTHORS wrote:
>>>>>   >>>>>>>>>> Hello Ron,
>>>>>   >>>>>>>>>>
>>>>>   >>>>>>>>>> Sending out of band congruent metadata may not be the
>>>>>answer
>>>>>   >>>>>>>>>> to all needs but it is one tool that we should keep.
>>>>>   >>>>>>>>>>
>>>>>   >>>>>>>>>> Not all metadata is tied to a specific packet, for
>>>>>example a
>>>>>   >>>>>>>>>> policy change in PCRF could lead to some metadata
>>>>>signaling,
>>>>>   >>>>>>>>>> the reaction time need not be immediate, few ms may
>>>>>not matter.
>>>>>   >>>>>>>>>>
>>>>>   >>>>>>>>>> As you point, if a packet is tied to a metadata a
>>>>>correlation
>>>>>   >>>>>>>>>> info can be set in both packet to deal with it (i.e
>>>>>metadata
>>>>>   >>>>>>>>>> expected flag in the SFC header, plus an id)
>>>>>   >>>>>>>>>>
>>>>>   >>>>>>>>>> Finally we can still send some limited metadata within
>>>>>a header.
>>>>>   >>>>>>>>>> This could be used for load balancers in particular if
>>>>>we
>>>>>   >>>>>>>>>> agree on a convention to locate "coarse grain policy"
>>>>>   >>>>>>>>>> / "fine grain policy" on reserved context headers.
>>>>>   >>>>>>>>>>
>>>>>   >>>>>>>>>> This seems to open up a lot of flexibility /
>>>>>innovations.
>>>>>   >>>>>>>>>>
>>>>>   >>>>>>>>>> On your last point, there is a question on how to make
>>>>>   >>>>>>>>>> metadata available to a Service Function. Current socket
>>>>>   >>>>>>>>>> connections for example do not allow to retrieve IP
>>>>>header
>>>>>   >>>>>>>>>> options. So I assume that SFC aware Service Functions
>>>>>will
>>>>>   >>>>>>>>>> need some (asynchronous
>>>>>   >>>>>>>>>> ?) API to retrieve SFC header information as well as
>>>>>in-band
>>>>>   >>>>>>>>>> metadata. I don't see out of band metadata transport
>>>>>adding
>>>>>   >>>>>>>>>> complexity, the same API can probably apply.
>>>>>   >>>>>>>>>>
>>>>>   >>>>>>>>>> The alternative option, allowing variable sized
>>>>>metadata in
>>>>>   >>>>>>>>>> the SFC header has some drawbacks as well, one being
>>>>>   >>>>>>>>>> fragmentation, and some switches expecting as well to
>>>>>look at
>>>>>   >>>>>>>>>> end user traffic headers for link load balancing. I
>>>>>would
>>>>>   >>>>>>>>>> agree that if we can accept these issues, then sending
>>>>>   >>>>>>>>>> off-line congruent metadata looses its interest.
>>>>>   >>>>>>>>>>
>>>>>   >>>>>>>>>> We need to take into account that both in-band and
>>>>>congruent
>>>>>   >>>>>>>>>> out-of-band metadata transport is not reliable. A
>>>>>packet loss
>>>>>   >>>>>>>>>> triggering retransmission would not lead to the
>>>>>identical
>>>>>   >>>>>>>>>> reconstruction of the associated metadata. In some
>>>>>cases, we
>>>>>   >>>>>>>>>> might thus even need non-congruent out-of-band reliable
>>>>>   >>>>>>>>>> metadata transport.
>>>>>   >>>>>>>>>>
>>>>>   >>>>>>>>>>
>>>>>   >>>>>>>>>>
>>>>>   >>>>>>>>>> Nicolas ________________________________________ From:
>>>>> Ron
>>>>>   >>>>>>>>>> Parker [[email-masked]<mailto:[email-masked]>] Sent:
>>>>>Wednesday,
>>>>>   >>>>>>>>>> March 12, 2014
>>>>>   >>>>>>>>>> 12:43 PM To: Nicolas BOUTHORS Cc: Jim Guichard
>>>>>(jguichar);
>>>>>   >>>>>>>>>> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>;
>>>>>sfc; Jamal Hadi Salim Subject: Re: [sfc]
>>>>>   >>>>>>>>>> draft-rijsman-sfc-metadata-considerations
>>>>>   >>>>>>>>>>
>>>>>   >>>>>>>>>> Nicolas,
>>>>>   >>>>>>>>>>
>>>>>   >>>>>>>>>> I understand the concept for out of band signaling of
>>>>>   >>>>>>>>>>metadata, but I am concerned that it introduces
>>>>>significant
>>>>>   >>>>>>>>>>complexity due to the potential race condition of
>>>>>receiving the
>>>>>   >>>>>>>>>>real packet before the metadata. While the real packet
>>>>>could
>>>>>   >>>>>>>>>>indicate that out of band metadata is expected, how can
>>>>>we
>>>>>   >>>>>>>>>>guarantee the order of reception? What if switching or
>>>>>routing
>>>>>   >>>>>>>>>>nodes apply hash based load balancing? What if the load
>>>>>   >>>>>>>>>>balancing understands SFC encaps and looks beyond it to
>>>>>the
>>>>>   >>>>>>>>>>original header to get better entropy?
>>>>>   >>>>>>>>>> Can we guarantee that the metadata and real packet
>>>>>will follow
>>>>>   >>>>>>>>>>the exact same path? If we can not, then
>>>>>implementations will
>>>>>   >>>>>>>>>>need to add ingress queuing to cope with the scenario.
>>>>>   >>>>>>>>>>
>>>>>   >>>>>>>>>> Also, do you feel that the increase in implementation
>>>>>   >>>>>>>>>> complexity at the service functions is reasonable?
>>>>>   >>>>>>>>>>
>>>>>   >>>>>>>>>> Thanks.
>>>>>   >>>>>>>>>>
>>>>>   >>>>>>>>>> Ron
>>>>>   >>>>>>>>>>
>>>>>   >>>>>>>>>>> On Mar 12, 2014, at 4:09 AM, "Nicolas BOUTHORS"
>>>>>   >>>>>>>>>>> <[email-masked]<mailto:[email-masked]>
>>>>><mailto:[email-masked]>> wrote:
>>>>>   >>>>>>>>>>>
>>>>>   >>>>>>>>>>> I think we must make a distinction between:
>>>>>   >>>>>>>>>>>
>>>>>   >>>>>>>>>>> - Metadata which should be part of the header defined
>>>>>as in
>>>>>   >>>>>>>>>>> band marking. - Metadata with can be passed out of
>>>>>band, for
>>>>>   >>>>>>>>>>> example congruent out of band signaling defined in
>>>>>the draft
>>>>>   >>>>>>>>>>>
>>>>>   >>>>>>>>>>> The former calls for a limited space in the header,
>>>>>true, The
>>>>>   >>>>>>>>>>> latter however does not incur any space limitation
>>>>>and is
>>>>>   >>>>>>>>>>> still fairly efficient and it remains compatible with
>>>>>a fixed
>>>>>   >>>>>>>>>>> size header used to route those signaling messages
>>>>>along the
>>>>>   >>>>>>>>>>> chain's service functions.
>>>>>   >>>>>>>>>>>
>>>>>   >>>>>>>>>>> Nicolas ________________________________________ From:
>>>>>   >>>>>>>>>>> Jim Guichard (jguichar) [[email-masked]<mailto:[email-masked]>] Sent:
>>>>>   >>>>>>>>>>> Tuesday, March 11, 2014 6:48 PM To: Ron Parker Cc:
>>>>>   >>>>>>>>>>> Nicolas BOUTHORS; [email-masked]<mailto:[email-masked]>
>>>>><mailto:[email-masked]>; sfc; Jamal Hadi Salim
>>>>>   >>>>>>>>>>> Subject: Re: [sfc]
>>>>> draft-rijsman-sfc-metadata-considerations
>>>>>   >>>>>>>>>>>
>>>>>   >>>>>>>>>>> Hi Ron,
>>>>>   >>>>>>>>>>>
>>>>>   >>>>>>>>>>> We can certainly have this discussion but we should
>>>>>first
>>>>>   >>>>>>>>>>> consider what information is necessary and if said
>>>>>   >>>>>>>>>>> information can fit within a fixed number of contexts
>>>>>in the
>>>>>   >>>>>>>>>>> majority of cases. Remember, the goal of being able
>>>>>to pass
>>>>>   >>>>>>>>>>> metadata through the network is to enhance service
>>>>>delivery,
>>>>>   >>>>>>>>>>> not pass the entire works of Shakespeare ;-)
>>>>>   >>>>>>>>>>>
>>>>>   >>>>>>>>>>> Sent from my iPhone
>>>>>   >>>>>>>>>>>
>>>>>   >>>>>>>>>>>> On Mar 7, 2014, at 3:52 AM, "Ron Parker"
>>>>>   >>>>>>>>>>>> <[email-masked]<mailto:[email-masked]>
>>>>><mailto:[email-masked]>> wrote:
>>>>>   >>>>>>>>>>>>
>>>>>   >>>>>>>>>>>> Nicolas,
>>>>>   >>>>>>>>>>>>
>>>>>   >>>>>>>>>>>> I see similar requirements from the 3gpp EPC side.
>>>>>I would
>>>>>   >>>>>>>>>>>> like to propose an OUI / TLV based approach where the
>>>>>   >>>>>>>>>>>> reserved OUI can be used for agreed upon types of
>>>>>common
>>>>>   >>>>>>>>>>>> metadata and vendor or other organizational OUIs can
>>>>>be used
>>>>>   >>>>>>>>>>>> to quickly innovate in the networks.
>>>>>   >>>>>>>>>>>> Simultaneously, I would also like to consider
>>>>>mechanisms
>>>>>   >>>>>>>>>>>> that are optimized for long lived flows so as to
>>>>>limit the
>>>>>   >>>>>>>>>>>> negative effects of packet growth.
>>>>>   >>>>>>>>>>>>
>>>>>   >>>>>>>>>>>> Ron
>>>>>   >>>>>>>>>>>>
>>>>>   >>>>>>>>>>>>
>>>>>   >>>>>>>>>>>>> On Mar 7, 2014, at 8:34 AM, "Nicolas BOUTHORS"
>>>>>   >>>>>>>>>>>>> <[email-masked]<mailto:[email-masked]>
>>>>><mailto:[email-masked]>> wrote:
>>>>>   >>>>>>>>>>>>>
>>>>>   >>>>>>>>>>>>> Hello Jim
>>>>>   >>>>>>>>>>>>>
>>>>>   >>>>>>>>>>>>> I have seen cases in Gi LAN, where subscriber related
>>>>>   >>>>>>>>>>>>> information is passed to a Web Proxy for HTTP header
>>>>>   >>>>>>>>>>>>> enrichment (aimed at some Web Content providers
>>>>>partners of
>>>>>   >>>>>>>>>>>>> the Mobile Operator).
>>>>>   >>>>>>>>>>>>> Information was an coded (persistent) subscriber id
>>>>>derived
>>>>>   >>>>>>>>>>>>> from the MSISDN, and couple of f customer profile
>>>>>related
>>>>>   >>>>>>>>>>>>> fields.
>>>>>   >>>>>>>>>>>>>
>>>>>   >>>>>>>>>>>>> In an sfc based Gi LAN, this entity should receive
>>>> >from the
>>>>>   >>>>>>>>>>>>> Classifier
>>>>>   >>>>>>>>>>>>>
>>>>>   >>>>>>>>>>>>> - A classification of the Content Provider ( Id,
>>>>>   >>>>>>>>>>>>> Category) based on traffic analysis - The MSISDN of
>>>>> the
>>>>>   >>>>>>>>>>>>> subscriber - Two subscriber policy fields (not tied
>>>>> to PCRF
>>>>>   >>>>>>>>>>>>> but belonging to the Subscriber DB) (Subscriber
>>>>> category,
>>>>>   >>>>>>>>>>>>> sub-category) - A session id (for logging and
>>>>>tracking
>>>>>   >>>>>>>>>>>>> purposes)
>>>>>   >>>>>>>>>>>>>
>>>>>   >>>>>>>>>>>>> The objective being to avoid having the HTTP Proxy
>>>>>to
>>>>>   >>>>>>>>>>>>> become a trusted application (interogate the
>>>>> subscriber DB,
>>>>>   >>>>>>>>>>>>> etc..)
>>>>>   >>>>>>>>>>>>>
>>>>>   >>>>>>>>>>>>>
>>>>>   >>>>>>>>>>>>> Nicolas
>>>>>   >>>>>>>>>>>>>
>>>>>   >>>>>>>>>>>>>
>>>>>   >>>>>>>>>>>>> ________________________________________ From: Jim
>>>>> Guichard
>>>>>   >>>>>>>>>>>>> (jguichar) [[email-masked]<mailto:[email-masked]>] Sent:
>>>>>   >>>>>>>>>>>>> Thursday, March 06, 2014 2:02 PM To: Jamal Hadi
>>>>>Salim;
>>>>>   >>>>>>>>>>>>> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>;
>>>>> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]> Cc:
>>>>>   >>>>>>>>>>>>> sfc Subject: Re: [sfc]
>>>>>   >>>>>>>>>>>>> draft-rijsman-sfc-metadata-considerations
>>>>>   >>>>>>>>>>>>>
>>>>>   >>>>>>>>>>>>> Hi Jamal,
>>>>>   >>>>>>>>>>>>>
>>>>>   >>>>>>>>>>>>> You said "It seems there's clear need for variable
>>>>> sized
>>>>>   >>>>>>>>>>>>> metadata".. I am not so convinced and would like to
>>>>> better
>>>>>   >>>>>>>>>>>>> understand the requirements before passing judgement.
>>>>> If we
>>>>>   >>>>>>>>>>>>> look at the use cases as presented thus far into
>>>>> the WG I
>>>>>   >>>>>>>>>>>>> have yet to see a single example of the need
>>>>> (noting that
>>>>>   >>>>>>>>>>>>> desire is not the same as need) - I am not saying
>>>>> there is
>>>>>   >>>>>>>>>>>>> no requirement but rather that we should not jump
>>>>> to the
>>>>>   >>>>>>>>>>>>> conclusion and build standards around a theory.
>>>>>   >>>>>>>>>>>>>
>>>>>   >>>>>>>>>>>>>
>>>>>   >>>>>>>>>>>>>
>>>>>   >>>>>>>>>>>>>> On 3/3/14, 6:35 AM, "Jamal Hadi Salim"
>>>>>   >>>>>>>>>>>>>> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>
>>>>>wrote:
>>>>>   >>>>>>>>>>>>>>
>>>>>   >>>>>>>>>>>>>> I like the doc - well written.
>>>>>   >>>>>>>>>>>>>>
>>>>>   >>>>>>>>>>>>>> Section 4.3 on metadata encoding.
>>>>>   >>>>>>>>>>>>>>
>>>>>   >>>>>>>>>>>>>> It seems there's clear need for variable sized
>>>>> metadata
>>>>>   >>>>>>>>>>>>>> (at least for http/app you seem to indicate the
>>>>> desire for
>>>>>   >>>>>>>>>>>>>>it).
>>>>>   >>>>>>>>>>>>>> For a datapath per-packet metadata, i feel the
>>>>> need is
>>>>>   >>>>>>>>>>>>>> just as important. Are we limited by the fact that
>>>>>   >>>>>>>>>>>>>> existing hardware may not be able to handle TLVs?
>>>>>For
>>>>>   >>>>>>>>>>>>>> example, I dont have a problem handling TLVs in a
>>>>> software
>>>>>   >>>>>>>>>>>>>>datapath.
>>>>>   >>>>>>>>>>>>>>
>>>>>   >>>>>>>>>>>>>> cheers, jamal
>>>>>   >>>>>>>>>>>>>>
>>>>>   >>>>>>>>>>>>>> _______________________________________________ sfc
>>>>>   >>>>>>>>>>>>>> mailing list [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
>>>>>   >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc
>>>>>   >>>>>>>>>>>>>
>>>>>   >>>>>>>>>>>>>
>>>>>   >>>>>>>>>>>>>
>>>>>   >>>>>>>>>>>>> _______________________________________________ sfc
>>>>> mailing
>>>>>   >>>>>>>>>>>>> list [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
>>>>> https://www.ietf.org/mailman/listinfo/sfc
>>>>>   >>>>>>>>>>
>>>>>   >>>>>>>>>> _______________________________________________ sfc
>>>>> mailing
>>>>>   >>>>>>>>>> list [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
>>>>> https://www.ietf.org/mailman/listinfo/sfc
>>>>>   >>>>>>>>>
>>>>>   >>>>>>>>> _______________________________________________ sfc
>>>>> mailing
>>>>>   >>>>>>>>> list [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
>>>>> https://www.ietf.org/mailman/listinfo/sfc
>>>>>   >>>>>>>>>
>>>>>   >>>>>>>>> _______________________________________________ sfc
>>>>> mailing
>>>>>   >>>>>>>>> list [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
>>>>> https://www.ietf.org/mailman/listinfo/sfc
>>>>>   >>>>>
>>>>>   >>>>> _______________________________________________ sfc mailing
>>>>> list
>>>>>   >>>>> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
>>>>> https://www.ietf.org/mailman/listinfo/sfc
>>>>>   >>>>>
>>>>>   >>
>>>>>   >>_______________________________________________
>>>>>   >>sfc mailing list
>>>>>   >>[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
>>>>>   >>https://www.ietf.org/mailman/listinfo/sfc
>>>>>   >
>>>>>   >_______________________________________________
>>>>>   >sfc mailing list
>>>>>   >[email-masked]<mailto:[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

_______________________________________________
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