Re: [sfc] NSH context headers: fixed/tlv

["Joel M. Halpern" <[e-mail]>]

Normally, an SF by its design knows what sort of metadata it needs.
part of the reason for having standard metadata TLV types (see draft) is 
to make this simpler.

So I don't see what the control plane would have to provide in those cases.

Further, if it is not standard and/or is not already built into the SF, 
I don't see how the control plane can provide the information as to 
which metadata the SF needs, since there is no way for the control to 
identify the semantics of the metadata other than the very type you are 
asking it to assign.

Yours,
Joel

On 12/3/15 4:28 PM, Carlos Pignataro (cpignata) wrote:
> Hi, Joel,
>
> The existing documented use-cases, mobility, DC, and broadband, contain different metadata fields. If an SF that can be used in any of these deployments is configured from the control-plane as part of an SFP, how does it know which fields are to be understood? Without profiles or explicit indication, seems a control-plane needs to set up relevant types of metadata (and for type 1 its schema).
>
> Thanks,
>
> — Carlos.
>
>> On Dec 3, 2015, at 9:54 AM, Joel M. Halpern <[e-mail]> wrote:
>>
>> Carlos, I am not following your reasoning here.
>> If MD-Type 2 is being used, then it is reasonable to expect that the service functions know what types they care about.  I don't think we have a problem of needing to later introduce a mandatory TLV that would cause a packet to be rejected by an SF that does not recognize it.  So what you ask for in terms of control support of MD-2 does not seem to be needed.
>>
>> Yours,
>> Joel
>>
>> On 12/3/15 8:57 AM, Carlos Pignataro (cpignata) wrote:
>>> Hi, Andy,
>>>
>>> This is a useful comment and area, please see inline.
>>>
>>>> On Dec 2, 2015, at 9:28 PM, Andrew G. Malis <[e-mail]
>>>> <mailto:[e-mail]>> wrote:
>>>>
>>>> Paul,
>>>>
>>>> Using the control plane to describe the context header allocation is,
>>>> of course, similar to how FECs managed by the control plane are used
>>>> to describe MPLS labels in the data plane.
>>>>
>>>> Except in this case, there are currently no provisions in
>>>> draft-ietf-sfc-control-plane-02 for the control plane to be able to
>>>> describe or identify the context header allocation for type 1.
>>>
>>> I agree with you that draft-ietf-sfc-control-plane-02 is underspecified.
>>> Section 2.3 scopes control-plane responsibilities that the doc does not
>>> tackle. However...
>>>
>>>> Would you be willing to provide text for this?
>>>>
>>>> Since type 2 is self-describing, there is less (no?) need for this
>>>> functionailty there.
>>>>
>>>
>>> … I disagree that the gap is only for MD Type 1.
>>>
>>> For MD Type 1, a schema can instruct the fields and format.
>>>
>>> For MD Type 2, the fact that it is self-describing actually imposes a
>>> much higher bar and responsibility for the control plane. Given the fact
>>> that there are potentially a ginormous amount of Type values, how does
>>> the control-plane convey what Types to expect, to use, which ones are
>>> mandatory, optional, what to do when unknown types are received, etc.
>>>
>>> Regardless of how the data is actually structured, the control-plane
>>> needs to convey what MD is expected, useful, and how. For MD Type 1,
>>> those are always organized in a certain way. For MD Type 2, they can be
>>> disorganized in a plurality of ways.
>>>
>>> Net-net, I think that the control-plane responsibility of instructing MD
>>> to expect. For MD Type 1, the schema. But MD Type 2 has the feature of
>>> complicating the data plane.
>>>
>>> Thanks,
>>>
>>> — Carlos.
>>>
>>>> Cheers,
>>>> Andy
>>>>
>>>> On Wed, Dec 2, 2015 at 2:17 PM, Paul Quinn (paulq) <[e-mail]
>>>> <mailto:[e-mail]>> wrote:
>>>>
>>>>     Hi Ron,
>>>>
>>>>     I'm not sure we gain much by adding that.  Given that a control
>>>>     plane is needed to provide semantic meaning to the metadata,
>>>>     relying on that control plane to "describe" the allocation seems
>>>>     reasonable.  It's certainly the approach taken in the open source
>>>>     world, and is working.
>>>>
>>>>     Paul
>>>>
>>>>>     On Dec 1, 2015, at 3:32 PM, Ron Parker
>>>>>     <[e-mail]
>>>>>     <mailto:[e-mail]>> wrote:
>>>>>
>>>>>     Paul,____
>>>>>
>>>>>     __ __
>>>>>
>>>>>     For type 1, would you consider incorporation of a “schema ID”
>>>>>     either within the 16 bytes or outside of them?   That would allow
>>>>>     for an IANA-type registry to make explicit the various complete
>>>>>     interpretations of the fixed-size metadata bytes.   A value could
>>>>>     be reserved for “enterprise specific” to allow for innovation and
>>>>>     experimental uses (whether or not an enterprise ID would be
>>>>>     included in this case could be for further discussion).   I think
>>>>>     some of the concerns around type 1 is the rigidity, but also the
>>>>>     not-so-explicitly structured nature of it and how that could lead
>>>>>     to interoperability difficulties.    My proposal would reduce
>>>>>     concerns around the latter, I believe.____
>>>>>
>>>>>     __ __
>>>>>
>>>>>     Thanks.____
>>>>>
>>>>>     __ __
>>>>>
>>>>>        Ron____
>>>>>
>>>>>     __ __
>>>>>
>>>>>     __ __
>>>>>
>>>>>     *From:*sfc [mailto:[e-mail]] *On Behalf Of *Paul
>>>>>     Quinn (paulq)
>>>>>     *Sent:* Tuesday, December 1, 2015 3:14 PM
>>>>>     *To:* Andrew G. Malis <[e-mail] <mailto:[e-mail]>>
>>>>>     *Cc:* [e-mail] <mailto:[e-mail]>
>>>>>     *Subject:* Re: [sfc] NSH context headers: fixed/tlv____
>>>>>
>>>>>     __ __
>>>>>
>>>>>     Hi Andy, ____
>>>>>
>>>>>     __ __
>>>>>
>>>>>     __ __
>>>>>
>>>>>     Please see below.____
>>>>>
>>>>>     __ __
>>>>>
>>>>>     __ __
>>>>>
>>>>>     Thanks____
>>>>>
>>>>>     Paul____
>>>>>
>>>>>     __ __
>>>>>
>>>>>     __ __
>>>>>
>>>>>         On Nov 23, 2015, at 10:50 AM, Andrew G. Malis
>>>>>         <[e-mail] <mailto:[e-mail]>> wrote:____
>>>>>
>>>>>         __ __
>>>>>
>>>>>         I agree with Paul B. that interoperability is best served by
>>>>>         using a header that accommodates the greatest number of
>>>>>         possible applications and use cases as the common
>>>>>         denominator. This argues for type 2 being the MUST to
>>>>>         implement, with type 1 being an optional optimization for
>>>>>         some particular use cases or applications that require at
>>>>>         most a particular number context headers. ____
>>>>>
>>>>>         __ __
>>>>>
>>>>>     __ __
>>>>>
>>>>>     PQ>  I don't follow that logic: the _easiest_ (in terms of
>>>>>     complexity, cost, etc.) option makes the most sense to mandate
>>>>>     since it allows for a broad implementation and helps ensure
>>>>>     adoption of the protocol.  Mandating a more complex option simply
>>>>>     slows the adoption.  This is exactly the conversation we had when
>>>>>     putting together the draft, and one that seems to resonate with
>>>>>     developers and operators alike. ____
>>>>>
>>>>>     __ __
>>>>>
>>>>>     PQ>  Also, let's not ignore history (you know the old adage ;)):
>>>>>     TLV and other variable length data plane protocols have not been
>>>>>     a success.  We can debate the reasons for that, but the fact
>>>>>     remains: simple data planes get adoption.  As Paul B. points out
>>>>>     below, we don't know all the metadata answers, but we do know
>>>>>     that a bounded amount of metadata is very important for SFC use
>>>>>     cases.  Let's use that fact, and a simple protocol to get
>>>>>     implementation out the door.____
>>>>>
>>>>>     __ __
>>>>>
>>>>>         In a separate email, Med asked a very reasonable question -
>>>>>         for type 1, why are there four mandatory context headers,
>>>>>         rather than 2, 3, 5, 10, etc.? The draft contains no
>>>>>         particular justification for this choice.____
>>>>>
>>>>>     __ __
>>>>>
>>>>>     PQ>  That's a very valid question.  The starting premise was
>>>>>     simple: a bounded set of fixed metadata.   Based on some
>>>>>     experience in the service space and some initial use case
>>>>>     discussion with operators, 4 provided some balance: reasonable in
>>>>>     that it provided some meaningful space, yet not so large as to
>>>>>     become unwieldy, all the while forcing some discipline.  Overall
>>>>>     that has proven to be true as implementations have been tested
>>>>>     and mapped to use cases.  Of course you can come up with cases
>>>>>     where 4 is too many, or too few, in which case the draft provides
>>>>>     a means to accommodate that.____
>>>>>
>>>>>     __ __
>>>>>
>>>>>     PQ>  I also think we need to be realistic.  We were urged during
>>>>>     WG formation by a large operator: the IETF cannot spend years
>>>>>     trying to solve the service chaining issue.  The need for an
>>>>>     interoperable protocol is acute and operators need to start
>>>>>     working on deployment (see the vibrancy of the open source
>>>>>     projects in this space).  The balance of type 1 and type 2 allows
>>>>>     for velocity and evolution. ____
>>>>>
>>>>>     __ __
>>>>>
>>>>>     __ __
>>>>>
>>>>>
>>>>>
>>>>>     ____
>>>>>
>>>>>         __ __
>>>>>
>>>>>         It’s true that there are two particular use
>>>>>         cases, draft-guichard-sfc-nsh-dc-allocation
>>>>>         and draft-napper-sfc-nsh-mobility-allocation, that look to
>>>>>         make good use of exactly 4 context headers. However, these
>>>>>         are just two particular examples, and not yet accepted by the
>>>>>         WG.  Further development of these drafts, or even
>>>>>         implementation, may show that four are insufficient.____
>>>>>
>>>>>         __ __
>>>>>
>>>>>         Cheers,____
>>>>>
>>>>>         Andy____
>>>>>
>>>>>         __ __
>>>>>
>>>>>         __ __
>>>>>
>>>>>         On Fri, Nov 20, 2015 at 12:20 PM, Bottorff, Paul
>>>>>         <[e-mail] <mailto:[e-mail]>> wrote:____
>>>>>
>>>>>             I think we all could agree that fixed headers are easier
>>>>>             to implement than TLVs, however that does not rationalize
>>>>>             mandating a fixed header implementation. It would
>>>>>             rationalize supporting only fixed length headers, however
>>>>>             we have been unable to do this. Options always weaken
>>>>>             standards agreement.____
>>>>>
>>>>>             ____
>>>>>
>>>>>             If the application requires TLVs, then it does not
>>>>>             provide any standards advantage to mandate support for
>>>>>             fixed headers. It will not be possible for an application
>>>>>             that requires TLVs to fall back to fixed length headers.
>>>>>             If they could, then we should eliminate the TLV option
>>>>>             from NSH. ____
>>>>>
>>>>>             ____
>>>>>
>>>>>             IMHO we should be looking at the abstract semantics for
>>>>>             meta-data before we consider how to encode it. Once we
>>>>>             decide what needs to be encoded then we can consider the
>>>>>             best encodings and what should be mandatory or optional. ____
>>>>>
>>>>>             ____
>>>>>
>>>>>             Cheers,____
>>>>>
>>>>>             ____
>>>>>
>>>>>             Paul ____
>>>>>
>>>>>             *From:* sfc [mailto:[e-mail]
>>>>>             <mailto:[e-mail]>] *On Behalf Of *Paul Quinn
>>>>>             (paulq)
>>>>>             *Sent:* Friday, November 20, 2015 6:27 AM
>>>>>             *To:* Qin Wu
>>>>>             *Cc:* [e-mail] <mailto:[e-mail]>;
>>>>>             Dolganow, Andrew (Andrew); [e-mail]
>>>>>             <mailto:[e-mail]>; Linda Dunbar
>>>>>             *Subject:* Re: [sfc] NSH context headers: fixed/tlv____
>>>>>
>>>>>             ____
>>>>>
>>>>>             ____
>>>>>
>>>>>                 On Nov 19, 2015, at 9:28 PM, Qin Wu
>>>>>                 <[e-mail] <mailto:[e-mail]>>
>>>>>                 wrote:____
>>>>>
>>>>>                 ____
>>>>>
>>>>>                 Hi, Andrew and Paul:____
>>>>>
>>>>>                 It looks I missed a lot of discussion regarding NSH
>>>>>                 context header in the past, thanks Paul to point me
>>>>>                 the archive.____
>>>>>
>>>>>                 Generally speaking, there is tradeoff between
>>>>>                 performance and flexibility.____
>>>>>
>>>>>                 ____
>>>>>
>>>>>                 ____
>>>>>
>>>>>             Absolutely, and that's the reason for offering the two
>>>>>             options: balance speed/simplicity and flexibility.____
>>>>>
>>>>>             ____
>>>>>
>>>>>             The philosophy is to mandate the simplest form of
>>>>>             metadata, enabling a broad implementation base.  If/when
>>>>>             more flexibility is needed a more flexible NSH type is
>>>>>             available, along with the associated tradeoffs.  That's
>>>>>             the balance that we decided to strike and it seems to be
>>>>>             reasonable and well accepted.____
>>>>>
>>>>>             ____
>>>>>
>>>>>             Thanks,____
>>>>>
>>>>>             Paul____
>>>>>
>>>>>             ____
>>>>>
>>>>>
>>>>>             _______________________________________________
>>>>>             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]
>>> https://www.ietf.org/mailman/listinfo/sfc
>>>
>>
>> _______________________________________________
>> sfc mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sfc
>