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

[Henry Fourie <[e-mail]>]

All,
   I am also in favor of MD2 being mandatory. I have not seen more comments on this ticket:
http://trac.tools.ietf.org/wg/sfc/trac/ticket/18

What is the current state of the NSH draft and plans to advance it to RFC status?

-        Louis

From: sfc [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Wednesday, December 02, 2015 10:32 PM
To: Dave Dolson; Carlos Pignataro (cpignata); Bottorff, Paul
Cc: Andrew G. Malis; Paul Quinn (paulq); [e-mail]
Subject: 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