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

["Carlos Pignataro (cpignata)" <[e-mail]>]

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