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

[Dave Dolson <[e-mail]>]

Thanks Jim. Obviously I wasn't thinking of the Routing Domain class of metadata.

It doesn't appear that the NSH draft takes a stance on whether or not functions 
should attempt to support all MD types if they do not utilize metadata.

My opinion is that it is acceptable for functions to ignore the MD if they don't use it.


-----Original Message-----
From: Jim Guichard (jguichar) [mailto:[e-mail]] 
Sent: Thursday, December 03, 2015 3:04 PM
To: Dave Dolson; Haeffner, Walter, Vodafone DE; David Melman; [e-mail]
Subject: Re: [sfc] NSH context headers: fixed/tlv

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