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

["Jim Guichard (jguichar)" <[e-mail]>]

Hi Dave,

Actually SFFs do need metadata if they are to support a number of use
cases - termination of chain is a classic example for preservation of VPN
forwarding context.

Jim

On 12/3/15, 2:47 PM, "sfc on behalf of Dave Dolson" <[e-mail]
on behalf of [e-mail]> wrote:

>My point about supporting all MD types was for SFF function only.
>I don't believe SFFs need to parse past the start of the NSH header to
>make a forwarding decision. SFFs don't need metadata or start of inner
>packet.
>
>
>
>
>From: Haeffner, Walter, Vodafone DE
>Sent: Thursday, December 3, 2015 2:21 PM
>To: Dave Dolson; David Melman; [e-mail]
>Subject: AW: [sfc] NSH context headers: fixed/tlv
>
>
>We don¹t need 256 variants of MD Type. As mentioned, two types seem to be
>sufficient to support a mixed environment.
>
>Metadata can cause a SF to reclassify which finally  may result in a
>modified forwarding behaviour (do something dependent on a network state
>like load condition, location of the user in case of mobile networks etc.
>).
>
>I don¹t understand your third statement. Dave, may you please explain in
>some more detail?
>
>Regards,
>Walter
>
>Von: sfc [mailto:[e-mail]] Im Auftrag von Dave Dolson
>Gesendet: Donnerstag, 3. Dezember 2015 17:58
>An: David Melman; [e-mail]
>Betreff: Re: [sfc] NSH context headers: fixed/tlv
>
>Actually, it would be possible to mandate, ³An SFF MUST support any value
>(0-255) of MD type.²
>
>The reason is that (as far as I can tell), forwarding decisions are not
>using metadata anyhow.
>
>This doesn¹t help with classifiers and SFs that need to use the metadata,
>but it might help with longevity of forwarding-plane silicon.
>
>
>-Dave
>
>
>From: sfc [mailto:[e-mail]] On Behalf Of David Melman
>Sent: Thursday, December 03, 2015 9:54 AM
>To: [e-mail]<mailto:[e-mail]>
>Subject: Re: [sfc] NSH context headers: fixed/tlv
>
>There is no doubt that fixed-size header parsing eases the silicon
>design, thereby  lowering the barrier for silicon vendors to support it.
>
>If we see that the main use cases are indeed satisfied by the fixed
>header size approach (MD Type 1), then making this the ³MUST² will bring
>the greatest level of adoption and compliance.
>
>MD Type 2 is the fallback for more complex cases that cannot be satisfied
>by MD Type 1. We should define MD Type 2 as ³SHOULD²  to encourage
>silicon vendors to support this, without deterring the less motivated
>vendors from supported MD Type 1.    Also, for use cases where no
>metadata is required, it would be easy for vendors to support the MD type
>2 without including any TLVs, i.e. just the fixed header.
>
>David
>
>From: sfc [mailto:[e-mail]] On Behalf Of Haeffner, Walter,
>Vodafone DE
>Sent: Thursday, December 03, 2015 11:30 AM
>To: [e-mail]<mailto:[e-mail]>;
>Dave Dolson; Carlos Pignataro (cpignata); Bottorff, Paul
>Cc: Paul Quinn (paulq); Andrew G. Malis; [e-mail]<mailto:[e-mail]>
>Subject: Re: [sfc] NSH context headers: fixed/tlv
>
>
>Dear all,
>
>
>
>Yes. Type Two should be a MUST and Type One should be optimized for the
>silicon use case. To encourage silicon vendors a MUST for MD#2 may help
>for penetration but I could live also with a SHOULD. Some feedback from
>silicon folks (Broadcom, Cisco, Intel) may support this discussion.
>Having all the performance optimization shortcuts between a VM and a
>physNIC in mind we should not leave out silicon based approaches.
>
>
>
>Regards, Walter
>
>
>Von: sfc [mailto:[e-mail]] Im Auftrag von
>[e-mail]<mailto:[e-mail]>
>Gesendet: Donnerstag, 3. Dezember 2015 07:32
>An: Dave Dolson; Carlos Pignataro (cpignata); Bottorff, Paul
>Cc: Andrew G. Malis; Paul Quinn (paulq); [e-mail]<mailto:[e-mail]>
>Betreff: Re: [sfc] NSH context headers: fixed/tlv
>
>Hi Dave, all,
>
>Fully agree that MD#2 is simple and covers the generic use cases while
>MD#1 is an optimization (modulo some further explanation about the size
>of the fixed fields, their number, interaction with the control plane,
>etc.).
>
>I¹m still in favor of having MD#2 be MUST.
>
>Cheers,
>Med
>
>De : sfc [mailto:[e-mail]] De la part de Dave Dolson
>Envoyé : mercredi 2 décembre 2015 22:24
>À : Carlos Pignataro (cpignata); Bottorff, Paul
>Cc : Paul Quinn (paulq); Andrew G. Malis;
>[e-mail]<mailto:[e-mail]>
>Objet : Re: [sfc] NSH context headers: fixed/tlv
>
>> we need to specify a MUST implement ‹ and that should be the simplest
>>to implement which allows for all common use cases ‹ in other words,
>>Type 1.
>
>It is indeed simple to implement the packet parser, but I think Type 1
>makes the control plane more complicated.
>How does an SF know what item is placed in slot 1 of MD Type 1?
>Type 2 allows the metadata to be self-describing.
>
>Also, for many users who don¹t use metadata, Type 2 is more efficient.
>
>So as I see it, Type 2 is the generic one and Type 1 is an optimization
>for special cases.
>
>
>-Dave
>
>
>
>
>From: sfc [mailto:[e-mail]] On Behalf Of Carlos Pignataro
>(cpignata)
>Sent: Wednesday, December 02, 2015 4:04 PM
>To: Bottorff, Paul
>Cc: Andrew G. Malis; Paul Quinn (paulq); [e-mail]<mailto:[e-mail]>
>Subject: Re: [sfc] NSH context headers: fixed/tlv
>
>Hi, Paul B.,
>
>Thanks for the conversation, please find one follow-up inline.
>
>On Dec 1, 2015, at 5:57 PM, Bottorff, Paul
><[e-mail]<mailto:[e-mail]>> wrote:
>
>Hi Carlos:
>
>More on this below,
>
>Cheers,
>
>Paul
>
>From: Carlos Pignataro (cpignata) [mailto:[e-mail]]
>Sent: Tuesday, December 01, 2015 2:32 PM
>To: Bottorff, Paul
>Cc: Paul Quinn (paulq); Andrew G. Malis; [e-mail]<mailto:[e-mail]>
>Subject: Re: [sfc] NSH context headers: fixed/tlv
>
>Paul B.,
>
>Please see inline.
>
>On Dec 1, 2015, at 5:12 PM, Bottorff, Paul
><[e-mail]<mailto:[e-mail]>> wrote:
>
>Hi Paul Q.:
>
>See inline,
>
>Cheers,
>
>Paul
>
>From: Carlos Pignataro (cpignata) [mailto:[e-mail]]
>Sent: Tuesday, December 01, 2015 1:52 PM
>To: Bottorff, Paul
>Cc: Paul Quinn (paulq); Andrew G. Malis; [e-mail]<mailto:[e-mail]>
>Subject: Re: [sfc] NSH context headers: fixed/tlv
>
>Hi, Paul B.,
>
>On Dec 1, 2015, at 4:45 PM, Bottorff, Paul
><[e-mail]<mailto:[e-mail]>> wrote:
>
>Hi Paul and Andew:
>
>
>Paul, I agree that fixed length is easiest to implement and will allow
>the most rapid adoption. Never the less, a standard is of no value if it
>does not improve interoperability.
>
>Of course. I do not see how interoperability is hampered in this case,
>however.
>PB>If an application needs TLVs then it can¹t interoperate with a system
>that needs fixed sized formats. In effect you have two divergent
>standards.
>
>
>If an SFP needs TLVs, it would be set with TLVs. That is part of the
>shared SFP context. MD Type 1 and MD Type 2 are protocol options, not
>divergent standards.
>PB>And if you have an SFP with one SF that needs TLVs and one that needs
>fixed headers you¹re going to translate the formats at the SFF? The
>result is the worst possible world where the switches need to know both
>formats and translate between them for various SFs.
>
>
>I am not sure what it means to have ³an SF that needs TLVs and one that
>needs fixed headers². Clearly, I am not proposing any translation!
>
>Don¹t forget there is a control-plane programming the SFs/SFFs, and that
>CP would set up the MD Type for a given SFP, so SFs do not Œneed¹
>specific encodings.
>
>Now, to mitigate the risk of having no intersection in capability (one SF
>supporting *only* Type 1 and one SF supporting *only* Type 2) is that we
>need to specify a MUST implement ‹ and that should be the simplest to
>implement which allows for all common use cases ‹ in other words, Type 1.
>
>See below.
>
>What I would suggest is either:
>1) make TLVs the mandatory format with fixed size optional;
>2) eliminate the TLV option entirely;
>3) change the NSH header format options so the fixed size header is
>always present with optional TLVs following the fixed sized header.
>
>To me, option 3 would not achieve a useful outcome. Basically, we could
>not count with a deterministically fixed header, and the flexible
>TLV-based option would always have ³stuff² before. Basically, this would
>negate the benefits of both MD Type 1 and MD Type 2.
>
>PB>For option 3 the fixed headers are at a constant offset which is what
>is important to parse them easily. It is possible for a switch or for
>software to use the fixed information at a fixed offset ever though TLV
>data may follow.
>
>
>I see the problem space quite differently: If an SFP needs shared context
>that fits in an MD Type 1, it is set with MD Type 1. If it needs more,
>then it needs to parse the TLVs anyway (and thus a fixed part followed by
>TLVs does not help).
>PB>TLVs always cost more than fixed size areas because they must encode
>individual TLs. An application that needs more than the fixed area can
>encode can use the fixed area for a portion of the meta-data and then add
>as many extension TLVs as are needed. The resulting encode will be at
>least as efficient as TLVs alone.
>
>Now, bring the conversation a level down from theoretical to practical,
>draft-guichard-sfc-nsh-dc-allocation-02,
>draft-meng-sfc-nsh-broadband-allocation, and
>draft-napper-sfc-nsh-mobility-allocation show what¹s needed for the WG
>use cases. MD Type 2 adds extra flexibility (at a price).
>PB>An talking very practically we are not omniscient. When we find we
>need a new piece of meta-data for these base use cases an extension TLV
>provides the options of retaining the existing formatted data while
>adding an additional piece of meta-data. If done carefully, this can
>allow backward compatibility with equipment that does not understand the
>new extensions.
>
>In other words, the minimum common denominator and the simpler to
>implement is MD Type 1.
>PB>My option 2 is the simpler option. Fixed length only. What is
>currently proposed is the most complex since it leads to multiple formats
>with translations between them.
>
>
>Please no translations!
>
>‹ Carlos.
>
>Thanks!
>
>‹ Carlos.
>
>If option 3 is chosen then applications can always count on the fixed
>sized header as their default.
>
>They could count with a fixed size part, not with a fixed sized header,
>if I understand the proposal correctly.
>
>PB>This is one better than the current proposal which can¹t count on
>either a fixed sized header or on a fixed size part at a known offset.
>
>Thanks,
>
>‹ Carlos.
>
>
>Cheers,
>
>Paul
>
>From: sfc [mailto:[e-mail]] On Behalf Of Paul Quinn (paulq)
>Sent: Tuesday, December 01, 2015 12:14 PM
>To: Andrew G. Malis
>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