Re: [sfc] SFC encapsulation chain ID

["NAPIERALA, MARIA H" <[e-mail]>]

Hi Jim,

It's the latter - I still want to use metadata within SFC header.
I tried to made this point several times in the past.

Maria

From: Jim Guichard (jguichar) [mailto:[e-mail]]
Sent: Friday, March 14, 2014 3:37 PM
To: NAPIERALA, MARIA H; [e-mail]; [e-mail]
Subject: SFC encapsulation chain ID

Hi Maria,

*note* - changed subject line

Why? If a label stack is doing the traffic steering then one could argue that you don't need the SFC header at all, or do you want to take advantage of the metadata carried within the SFC encapsulation?

From: <NAPIERALA>, MARIA H <[e-mail]<mailto:[e-mail]>>
Date: Friday, March 14, 2014 at 2:29 PM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

Mike,

It was discussed before, some months ago.
My point is that chain ID can be implicit (e.g., represented by an MPLS label).  We should have at least a no-op or NULL option for explicit chain ID.

Maria

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]
Sent: Friday, March 14, 2014 3:13 PM
To: NAPIERALA, MARIA H; [e-mail]<mailto:[e-mail]>
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

Maria,

Sure, but then why not just do that, then?  I assume that the method of service chaining to which you are referring has some limitations that you are expecting to overcome with SFC.  IMO, one of the benefits of SFC over other methods of implementing service chaining is having a mandatory chain ID field.  Sure, the chain ID could be carried in some other field of the IP packet, but I think that draft-boucadair-sfc-design-analysis (sect 6) does an excellent job of demonstrating why the SFC header is the better option.

Is there a better thread for discussing the merits of a Chain ID?

-MikeB





________________________________
From: [e-mail]<[e-mail]<mailto:[e-mail][e-mail]>>
To: Ron Parker<[e-mail]<mailto:[e-mail]>>,Surendra Kumar (smkumar)<[e-mail]<mailto:[e-mail]>>,Joel M. Halpern<[e-mail]<mailto:[e-mail]>>
cc: [e-mail]<[e-mail]<mailto:[e-mail][e-mail]>>
Sent: Friday, March 14, 2014
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

Well, we can do service chaining today without such explicit ID (and not based on VLAN stitching). So, it is possible.


Maria

> -----Original Message-----
>

From: Ron Parker [mailto:[e-mail]]
> Sent: Friday, March 14, 2014 2:28 PM
> To: Surendra Kumar (smkumar); Joel M. Halpern; NAPIERALA, MARIA H
> Cc: [e-mail]<mailto:[e-mail]>
> Subject: RE: [sfc] draft-rijsman-sfc-metadata-considerations
>
> 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:[e-mail]] On Behalf Of Surendra Kumar
> (smkumar)
> Sent: Friday, March 14, 2014 1:46 PM
> To: Joel M. Halpern; NAPIERALA, MARIA H
> Cc: [e-mail]<mailto:[e-mail]>
> 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" <[e-mail]<mailto:[e-mail]>> 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:[e-mail]] *On Behalf Of *Jmh.direct
> >> *Sent:* Thursday, March 13, 2014 12:12 PM
> >> *To:* [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;
> >>[e-mail]<mailto:[e-mail]>
> >> *Cc:* [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;
> >>[e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;
> >>[e-mail]<mailto:[e-mail]>
> >> *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)" <[e-mail]
<mailto:[e-mail]%0b>> >> <mailto:[e-mail]>>
> >> To: Lucy yong <[e-mail]
<mailto:[e-mail]%0b>> >> <mailto:[e-mail]>>,"Surendra Kumar (smkumar)"
> >> <[e-mail] <mailto:[e-mail]<mailto:[e-mail]%20%3cmailto:[e-mail]>>>,"Jim Guichard
> (jguichar)"
> >> <[e-mail] <mailto:[e-mail]<mailto:[e-mail]%20%3cmailto:[e-mail]>>>
> >> CC: Nicolas BOUTHORS <[e-mail]
<mailto:[e-mail]%0b>> >> <mailto:[e-mail]>>,sfc <[e-mail]
<mailto:[e-mail]%0b>> >> <mailto:[e-mail]>>,Jamal Hadi Salim <[e-mail]
<mailto:[e-mail]%0b>> >> <mailto:[e-mail]>>,Ron Parker
> >> <[e-mail]
<mailto:[e-mail]%0b>> >> <mailto:[e-mail]>>,"[e-mail]
> >> <mailto:[e-mail]><mailto:[e-mail]%0b%3e%20%3e%3e%20%3cmailto:[e-mail]%3e>" <[e-mail]
<mailto:[e-mail]%0b>> >> <mailto:[e-mail]>>,"Joel M. Halpern"
> <[e-mail]
<mailto:[e-mail]%0b>> >> <mailto:[e-mail]>>
> >>
> >> 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" <[e-mail]
<mailto:[e-mail]%0b>> >> <mailto:[e-mail]>> 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:[e-mail]]
> >> >>Sent: Wednesday, March 12, 2014 4:38 PM
> >> >>To: Lucy yong
> >> >>Cc: Joel M. Halpern; Nicolas BOUTHORS; Ron Parker;
> >> >>[e-mail]<mailto:[e-mail]> <mailto:[e-mail]>; 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" <[e-mail]
<mailto:[e-mail]%0b>> >><mailto:[e-mail]>> 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" <[e-mail]
<mailto:[e-mail]%0b>> >><mailto:[e-mail]>> 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:[e-mail]]
> >> >>>> Sent: Wednesday, March 12, 2014 2:35 PM
> >> >>>> To: Lucy yong; Nicolas BOUTHORS; Ron Parker
> >> >>>> Cc: Jim Guichard (jguichar); [e-mail]<mailto:[e-mail]>
> >><mailto:[e-mail]>; 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:[e-mail]] 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); [e-mail]<mailto:[e-mail]>
> >><mailto:[e-mail]>; 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:[e-mail]] Sent: Wednesday, March 12, 2014
> >>1:19
> >> >>>>>> PM
> >> >>>>>> To: Lucy yong; Nicolas BOUTHORS; Ron Parker Cc: Jim Guichard
> >> >>>>>> (jguichar); [e-mail]<mailto:[e-mail]>
> >><mailto:[e-mail]>; 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:[e-mail]] Sent: Wednesday, March
> >>12,
> >> >>>>>>> 2014 12:25 PM To: Lucy yong; Joel M. Halpern; Nicolas
> >>BOUTHORS;
> >> >>>>>>> Ron Parker Cc: Jim Guichard (jguichar);
> [e-mail]<mailto:[e-mail]>
> >><mailto:[e-mail]>;
> >> >>>>>>> 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:[e-mail]] Sent: Wednesday, March 12,
> >>2014
> >> >>>>>>>> 11:18 AM To: Lucy yong; Nicolas BOUTHORS; Ron Parker Cc:
> >>Jim
> >> >>>>>>>> Guichard (jguichar); [e-mail]<mailto:[e-mail]>
> >><mailto:[e-mail]>; 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:[e-mail]] On Behalf Of Joel M.
> Halpern
> >> >>>>>>>>> Sent: Wednesday, March 12, 2014 9:21 AM To: Nicolas
> >>BOUTHORS;
> >> >>>>>>>>> Ron Parker Cc: Jim Guichard (jguichar);
> >>[e-mail]<mailto:[e-mail]> <mailto:[e-mail]>;
> >> >>>>>>>>> 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 [[e-mail]<mailto:[e-mail]>] Sent:
> Wednesday,
> >> >>>>>>>>>> March 12, 2014
> >> >>>>>>>>>> 12:43 PM To: Nicolas BOUTHORS Cc: Jim Guichard
> >>(jguichar);
> >> >>>>>>>>>> [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>; 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"
> >> >>>>>>>>>>> <[e-mail]
<mailto:[e-mail]%0b>> >><mailto:[e-mail]>> 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) [[e-mail]<mailto:[e-mail]>] Sent:
> >> >>>>>>>>>>> Tuesday, March 11, 2014 6:48 PM To: Ron Parker Cc:
> >> >>>>>>>>>>> Nicolas BOUTHORS; [e-mail]<mailto:[e-mail]>
> >><mailto:[e-mail]>; 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"
> >> >>>>>>>>>>>> <[e-mail]
<mailto:[e-mail]%0b>> >><mailto:[e-mail]>> 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"
> >> >>>>>>>>>>>>> <[e-mail]
<mailto:[e-mail]%0b>> >><mailto:[e-mail]>> 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) [[e-mail]<mailto:[e-mail]>] Sent:
> >> >>>>>>>>>>>>> Thursday, March 06, 2014 2:02 PM To: Jamal Hadi
> Salim;
> >> >>>>>>>>>>>>> [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>;
> >>[e-mail]<mailto:[e-mail]> <mailto:[e-mail]> 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"
> >> >>>>>>>>>>>>>> <[e-mail] <mailto:[e-mail]<mailto:[e-mail]%20%3cmailto:[e-mail]>>>
> 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 [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
> >> >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>> _______________________________________________ sfc
> >>mailing
> >> >>>>>>>>>>>>> list [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
> >>https://www.ietf.org/mailman/listinfo/sfc
> >> >>>>>>>>>>
> >> >>>>>>>>>> _______________________________________________ sfc
> >>mailing
> >> >>>>>>>>>> list [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
> >>https://www.ietf.org/mailman/listinfo/sfc
> >> >>>>>>>>>
> >> >>>>>>>>> _______________________________________________ sfc
> >>mailing
> >> >>>>>>>>> list [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
> >>https://www.ietf.org/mailman/listinfo/sfc
> >> >>>>>>>>>
> >> >>>>>>>>> _______________________________________________ sfc
> >>mailing
> >> >>>>>>>>> list [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
> >>https://www.ietf.org/mailman/listinfo/sfc
> >> >>>>>
> >> >>>>> _______________________________________________ sfc mailing
> >>list
> >> >>>>> [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
> >>https://www.ietf.org/mailman/listinfo/sfc
> >> >>>>>
> >> >>
> >> >>_______________________________________________
> >> >>sfc mailing list
> >> >>[e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
> >> >>https://www.ietf.org/mailman/listinfo/sfc
> >> >
> >> >_______________________________________________
> >> >sfc mailing list
> >> >[e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
> >> >https://www.ietf.org/mailman/listinfo/sfc
> >>
> >
> >_______________________________________________
> >sfc mailing list
> >[e-mail]<mailto:[e-mail]>
> >https://www.ietf.org/mailman/listinfo/sfc
>
> _______________________________________________
> sfc mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/sfc

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