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

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Tue, 1 Dec 2015 20:13:37 +0000

Hi Andy,

Please see below.

Thanks
Paul

On Nov 23, 2015, at 10:50 AM, Andrew G. Malis <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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:[email-masked]<mailto:[email-masked]>] On Behalf Of Paul Quinn (paulq)
Sent: Friday, November 20, 2015 6:27 AM
To: Qin Wu
Cc: [email-masked]<mailto:[email-masked]>; Dolganow, Andrew (Andrew); [email-masked]<mailto:[email-masked]>; Linda Dunbar
Subject: Re: [sfc] NSH context headers: fixed/tlv

On Nov 19, 2015, at 9:28 PM, Qin Wu <[email-masked]<mailto:[email-masked]>> 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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

---

From: Ron Parker <[email-masked]>
Date: Tue, 1 Dec 2015 20:32:42 +0000

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:[email-masked]] On Behalf Of Paul Quinn (paulq)
Sent: Tuesday, December 1, 2015 3:14 PM
To: Andrew G. Malis <[email-masked]>
Cc: [email-masked]
Subject: Re: [sfc] NSH context headers: fixed/tlv

Hi Andy,

Please see below.

Thanks
Paul

Cheers,
Andy

Cheers,

Paul

Hi, Andrew and Paul:

Thanks,
Paul

---

From: "Bottorff, Paul" <[email-masked]>
Date: Tue, 1 Dec 2015 21:45:08 +0000

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.

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.

If option 3 is chosen then applications can always count on the fixed sized header as their default.

Cheers,

Paul

From: sfc [mailto:[email-masked]] On Behalf Of Paul Quinn (paulq)
Sent: Tuesday, December 01, 2015 12:14 PM
To: Andrew G. Malis
Cc: [email-masked]
Subject: Re: [sfc] NSH context headers: fixed/tlv

Hi Andy,

Please see below.

Thanks
Paul

Cheers,
Andy

Cheers,

Paul

Hi, Andrew and Paul:

Thanks,
Paul

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 1 Dec 2015 21:52:16 +0000

Hi, Paul B.,

> On Dec 1, 2015, at 4:45 PM, Bottorff, Paul <[email-masked]> wrote:
> 
> Hi Paul and Andew:
> 
> 

Of course. I do not see how interoperability is hampered in this case, however.

> 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.

> 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.

Thanks,

— Carlos.

> On Nov 23, 2015, at 10:50 AM, Andrew G. Malis <[email-masked] <mailto:[email-masked]>> wrote:
> 
> On Fri, Nov 20, 2015 at 12:20 PM, Bottorff, Paul <[email-masked] <mailto:[email-masked]>> wrote:
> From: sfc [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Paul Quinn (paulq)
> Cc: [email-masked] <mailto:[email-masked]>; Dolganow, Andrew (Andrew); [email-masked] <mailto:[email-masked]>; Linda Dunbar
> On Nov 19, 2015, at 9:28 PM, Qin Wu <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi, Andrew and Paul:
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sfc <https://www.ietf.org/mailman/listinfo/sfc>
> 
> 
> [email-masked]

---

From: "Bottorff, Paul" <[email-masked]>
Date: Tue, 1 Dec 2015 22:06:16 +0000

Hi Ron:

I’m in agreement that we should have a code point designating the format and content of the 16 bytes. To allow for proprietary implementations we could also designate an experimental format.

Cheers,

Paul

From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Tuesday, December 01, 2015 12:33 PM
To: Paul Quinn (paulq); Andrew G. Malis
Cc: [email-masked]
Subject: Re: [sfc] NSH context headers: fixed/tlv

Paul,

Thanks.

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of Paul Quinn (paulq)
Sent: Tuesday, December 1, 2015 3:14 PM
To: Andrew G. Malis <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] NSH context headers: fixed/tlv

Hi Andy,

Please see below.

Thanks
Paul

Cheers,
Andy

Cheers,

Paul

Hi, Andrew and Paul:

Thanks,
Paul

---

From: "Bottorff, Paul" <[email-masked]>
Date: Tue, 1 Dec 2015 22:12:14 +0000

Hi Paul Q.:

See inline,

Cheers,

Paul

From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
Sent: Tuesday, December 01, 2015 1:52 PM
To: Bottorff, Paul
Cc: Paul Quinn (paulq); Andrew G. Malis; [email-masked]
Subject: Re: [sfc] NSH context headers: fixed/tlv

Hi, Paul B.,

On Dec 1, 2015, at 4:45 PM, Bottorff, Paul <[email-masked]<mailto:[email-masked]>> wrote:

Hi Paul and Andew:

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.

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.

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

Hi Andy,

Please see below.

Thanks
Paul

Cheers,
Andy

Cheers,

Paul

Hi, Andrew and Paul:

Thanks,
Paul

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 1 Dec 2015 22:32:05 +0000

Paul B.,

Please see inline.

> On Dec 1, 2015, at 5:12 PM, Bottorff, Paul <[email-masked]> wrote:
> 
> Hi Paul Q.:
> 
> See inline,
> 
> Cheers,
> 
> Paul
> 
> From: Carlos Pignataro (cpignata) [mailto:[email-masked] <mailto:[email-masked]>]
> Cc: Paul Quinn (paulq); Andrew G. Malis; [email-masked] <mailto:[email-masked]>
> On Dec 1, 2015, at 4:45 PM, Bottorff, Paul <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi Paul and Andew:
> 
> 

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.

See below.

> 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 offse…

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).

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).

In other words, the minimum common denominator and the simpler to implement is MD Type 1.

Thanks!

— Carlos.

> Cc: [email-masked] <mailto:[email-masked]>

---

From: "Bottorff, Paul" <[email-masked]>
Date: Tue, 1 Dec 2015 22:57:56 +0000

Hi Carlos:

More on this below,

Cheers,

Paul

From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
Sent: Tuesday, December 01, 2015 2:32 PM
To: Bottorff, Paul
Cc: Paul Quinn (paulq); Andrew G. Malis; [email-masked]
Subject: Re: [sfc] NSH context headers: fixed/tlv

Paul B.,

Please see inline.

On Dec 1, 2015, at 5:12 PM, Bottorff, Paul <[email-masked]<mailto:[email-masked]>> wrote:

Hi Paul Q.:

See inline,

Cheers,

Paul

From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
Sent: Tuesday, December 01, 2015 1:52 PM
To: Bottorff, Paul
Cc: Paul Quinn (paulq); Andrew G. Malis; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] NSH context headers: fixed/tlv

Hi, Paul B.,

Hi Paul and Andew:

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.

See below.

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.

Thanks!

— Carlos.

Thanks,

— Carlos.

Cheers,

Paul

Hi Andy,

Please see below.

Thanks
Paul

Cheers,
Andy

Cheers,

Paul

Hi, Andrew and Paul:

Thanks,
Paul

---

From: Sumandra Majee <[email-masked]>
Date: Tue, 1 Dec 2015 23:09:31 +0000

>>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 f…

I do agree with the above statement. SFP may choose to ignore MD type 2 altogether or not bother to parse also.
Having a fixed sized header leads to a more efficient buffer management, aligning with cache line etc. etc., so more friendly for programmers. It is by no means an optimal design for carrying a variety of information.

However I do think there should be some code point to figure out the context portion of MD=2 payload. It did come across in another thread. One of the code point should be undefined/private.

From: sfc <[email-masked]<mailto:[email-masked]>> on behalf of "Carlos Pignataro (cpignata)" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, December 1, 2015 at 2:32 PM
To: "Bottorff, Paul" <[email-masked]<mailto:[email-masked]>>
Cc: "Andrew G. Malis" <[email-masked]<mailto:[email-masked]>>, "Paul Quinn (paulq)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] NSH context headers: fixed/tlv

Paul B.,

Please see inline.

Hi Paul Q.:

See inline,

Cheers,

Paul

Hi, Paul B.,

Hi Paul and Andew:

See below.

Thanks!

— Carlos.

Thanks,

— Carlos.

Cheers,

Paul

Hi Andy,

Please see below.

Thanks
Paul

Cheers,
Andy

Cheers,

Paul

Hi, Andrew and Paul:

Thanks,
Paul

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 2 Dec 2015 21:04:26 +0000

Hi, Paul B.,

Thanks for the conversation, please find one follow-up inline.

> On Dec 1, 2015, at 5:57 PM, Bottorff, Paul <[email-masked]> wrote:
> 
> Hi Carlos:
> 
> More on this below,
> 
> Cheers,
> 
> Paul
> 
> On Dec 1, 2015, at 5:12 PM, Bottorff, Paul <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi Paul Q.:
> 
> See inline,
> 
> Cheers,
> 
> Paul
> 

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.

> 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.

---

From: Dave Dolson <[email-masked]>
Date: Wed, 2 Dec 2015 21:23:44 +0000

> 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:[email-masked]] On Behalf Of Carlos Pignataro (cpignata)
Sent: Wednesday, December 02, 2015 4:04 PM
To: Bottorff, Paul
Cc: Andrew G. Malis; Paul Quinn (paulq); [email-masked]
Subject: Re: [sfc] NSH context headers: fixed/tlv

Hi, Paul B.,

On Dec 1, 2015, at 5:57 PM, Bottorff, Paul <[email-masked]<mailto:[email-masked]>> wrote:

Hi Carlos:

More on this below,

Cheers,

Paul

Paul B.,

Please see inline.

Hi Paul Q.:

See inline,

Cheers,

Paul

Hi, Paul B.,

Hi Paul and Andew:

See below.

Please no translations!

— Carlos.

Thanks!

— Carlos.

Thanks,

— Carlos.

Cheers,

Paul

Hi Andy,

Please see below.

Thanks
Paul

Cheers,
Andy

Cheers,

Paul

Hi, Andrew and Paul:

Thanks,
Paul

---

From: "Bottorff, Paul" <[email-masked]>
Date: Wed, 2 Dec 2015 21:30:12 +0000

Hi Dave:

Agreed, the self-describing nature of TLVs makes them easier to control and also makes the system less prone to configuration errors or software bugs.

Cheers,

Paul

From: Dave Dolson [mailto:[email-masked]]
Sent: Wednesday, December 02, 2015 1:24 PM
To: Carlos Pignataro (cpignata); Bottorff, Paul
Cc: Andrew G. Malis; Paul Quinn (paulq); [email-masked]
Subject: RE: [sfc] NSH context headers: fixed/tlv

-Dave

From: sfc [mailto:[email-masked]] On Behalf Of Carlos Pignataro (cpignata)
Sent: Wednesday, December 02, 2015 4:04 PM
To: Bottorff, Paul
Cc: Andrew G. Malis; Paul Quinn (paulq); [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] NSH context headers: fixed/tlv

Hi, Paul B.,

Hi Carlos:

More on this below,

Cheers,

Paul

Paul B.,

Please see inline.

Hi Paul Q.:

See inline,

Cheers,

Paul

Hi, Paul B.,

Hi Paul and Andew:

See below.

Please no translations!

— Carlos.

Thanks!

— Carlos.

Thanks,

— Carlos.

Cheers,

Paul

Hi Andy,

Please see below.

Thanks
Paul

Cheers,
Andy

Cheers,

Paul

Hi, Andrew and Paul:

Thanks,
Paul

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Wed, 2 Dec 2015 22:17:18 +0000

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 <[email-masked]<mailto:[email-masked]>> wrote:

Paul,

Thanks.

   Ron

Hi Andy,

Please see below.

Thanks
Paul

Cheers,
Andy

Cheers,

Paul

Hi, Andrew and Paul:

Thanks,
Paul

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 2 Dec 2015 18:18:04 -0800

Dave,

> So as I see it, Type 2 is the generic one and Type 1 is an optimization
That’s exactly as I see it as well (stated in an earlier email in this
discussion).

Cheers,
Andy

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 2 Dec 2015 18:28:59 -0800

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. Would you be
willing to provide text for this?

Since type 2 is self-describing, there is less (no?) need for this
functionailty there.

Cheers,
Andy

On Wed, Dec 2, 2015 at 2:17 PM, Paul Quinn (paulq) <[email-masked]> 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 <[email-masked]>
> 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:[email-masked] <[email-masked]>] *On
> Behalf Of *Paul Quinn (paulq)
> *Sent:* Tuesday, December 1, 2015 3:14 PM
> *To:* Andrew G. Malis <[email-masked]>
> *Cc:* [email-masked]
> *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 <[email-masked]> 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 <[email-masked]>
> 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:[email-masked]] *On Behalf Of *Paul Quinn
> (paulq)
> *Sent:* Friday, November 20, 2015 6:27 AM
> *To:* Qin Wu
> *Cc:* [email-masked]; Dolganow, Andrew (Andrew); [email-masked]; Linda
> Dunbar
> *Subject:* Re: [sfc] NSH context headers: fixed/tlv
>
>
>
>
>
> On Nov 19, 2015, at 9:28 PM, Qin Wu <[email-masked]> 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.
>
> 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
>
>
>
>

---

From: <[email-masked]>
Date: Thu, 3 Dec 2015 06:32:00 +0000

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:[email-masked]] 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; [email-masked]
Objet : Re: [sfc] NSH context headers: fixed/tlv

-Dave

Hi, Paul B.,

Hi Carlos:

More on this below,

Cheers,

Paul

Paul B.,

Please see inline.

Hi Paul Q.:

See inline,

Cheers,

Paul

Hi, Paul B.,

Hi Paul and Andew:

See below.

Please no translations!

— Carlos.

Thanks!

— Carlos.

Thanks,

— Carlos.

Cheers,

Paul

Hi Andy,

Please see below.

Thanks
Paul

Cheers,
Andy

Cheers,

Paul

Hi, Andrew and Paul:

Thanks,
Paul

---

From: "Haeffner, Walter, Vodafone DE" <[email-masked]>
Date: Thu, 3 Dec 2015 09:30:03 +0000

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:[email-masked]] Im Auftrag von [email-masked]
Gesendet: Donnerstag, 3. Dezember 2015 07:32
An: Dave Dolson; Carlos Pignataro (cpignata); Bottorff, Paul
Cc: Andrew G. Malis; Paul Quinn (paulq); [email-masked]
Betreff: Re: [sfc] NSH context headers: fixed/tlv

Hi Dave, all,

Cheers,
Med

Cc : Paul Quinn (paulq); Andrew G. Malis; [email-masked]<mailto:[email-masked]>

-Dave

Hi, Paul B.,

Hi Carlos:

More on this below,

Cheers,

Paul

Paul B.,

Please see inline.

Hi Paul Q.:

See inline,

Cheers,

Paul

Hi, Paul B.,

Hi Paul and Andew:

See below.

Please no translations!

— Carlos.

Thanks!

— Carlos.

Thanks,

— Carlos.

Cheers,

Paul

Hi Andy,

Please see below.

Thanks
Paul

Cheers,
Andy

Cheers,

Paul

Hi, Andrew and Paul:

Thanks,
Paul

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Thu, 3 Dec 2015 13:34:15 +0000

Hi Ron,

Paul

Paul,

Thanks.

   Ron

Hi Andy,

Please see below.

Thanks
Paul

Cheers,
Andy

Cheers,

Paul

Hi, Andrew and Paul:

Thanks,
Paul

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 3 Dec 2015 13:46:24 +0000

Med,

I have to admit I am having a hard time following the technical grounds for the hypothesis that MD Type 2 is simpler for the data plane. More generic, yes. But in my view, too generic.

Since you bring up use cases, the DC, Mobility, and Broadband use cases are shown in I-Ds to be covered by MD Type 1. Perhaps you could share what’s *not* possible with MD Type 1 in the useful use cases?

Thanks,

— Carlos.

> On Dec 3, 2015, at 1:32 AM, [email-masked] wrote:
> 
> Hi Dave, all,
> 
> De : sfc [mailto:[email-masked] <mailto:[email-masked]>] De la part de Dave Dolson
> Cc : Paul Quinn (paulq); Andrew G. Malis; [email-masked] <mailto:[email-masked]>
> From: sfc [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Carlos Pignataro (cpignata)
> Cc: Andrew G. Malis; Paul Quinn (paulq); [email-masked] <mailto:[email-masked]>
> On Dec 1, 2015, at 5:57 PM, Bottorff, Paul <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi Carlos:
> 
> More on this below,
> 
> Cheers,
> 
> Paul
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 3 Dec 2015 13:57:57 +0000

Hi, Andy,

This is a useful comment and area, please see inline.

> On Dec 2, 2015, at 9:28 PM, Andrew G. Malis <[email-masked]> 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) <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Ron,
> 
>> On Dec 1, 2015, at 3:32 PM, Ron Parker <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Paul,
>> 
>> 
>> 
>>   <>
>> To: Andrew G. Malis <[email-masked] <mailto:[email-masked]>>

---

From: David Melman <[email-masked]>
Date: Thu, 3 Dec 2015 14:54:00 +0000

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:[email-masked]] On Behalf Of Haeffner, Walter, Vodafone DE
Sent: Thursday, December 03, 2015 11:30 AM
To: [email-masked]; Dave Dolson; Carlos Pignataro (cpignata); Bottorff, Paul
Cc: Paul Quinn (paulq); Andrew G. Malis; [email-masked]
Subject: Re: [sfc] NSH context headers: fixed/tlv

Dear all,

Regards, Walter

Von: sfc [mailto:[email-masked]] Im Auftrag von [email-masked]<mailto:[email-masked]>

Hi Dave, all,

Cheers,
Med

-Dave

Hi, Paul B.,

Hi Carlos:

More on this below,

Cheers,

Paul

Paul B.,

Please see inline.

Hi Paul Q.:

See inline,

Cheers,

Paul

Hi, Paul B.,

Hi Paul and Andew:

See below.

Please no translations!

— Carlos.

Thanks!

— Carlos.

Thanks,

— Carlos.

Cheers,

Paul

Hi Andy,

Please see below.

Thanks
Paul

Cheers,
Andy

Cheers,

Paul

Hi, Andrew and Paul:

Thanks,
Paul

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 3 Dec 2015 09:54:08 -0500

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:
>> On Dec 2, 2015, at 9:28 PM, Andrew G. Malis <[email-masked]
>> <mailto:[email-masked]>> 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.
>>
>> 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...
>
> 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
>>
>>     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
>>>     <[email-masked]
>>>     <mailto:[email-masked]>> 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:[email-masked]] *On Behalf Of *Paul
>>>     Quinn (paulq)
>>>     *To:* Andrew G. Malis <[email-masked] <mailto:[email-masked]>>
>>>     *Cc:* [email-masked] <mailto:[email-masked]>
>>>     *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
>>>         <[email-masked] <mailto:[email-masked]>> 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. ____
>>>
>>>     __ __
>>>
>>>     __ __
>>>
>>>
>>>
>>>     ____
>>>
>>>         __ __
>>>
>>>         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
>>>         <[email-masked] <mailto:[email-masked]>> 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:[email-masked]
>>>             <mailto:[email-masked]>] *On Behalf Of *Paul Quinn
>>>             (paulq)
>>>             *Cc:* [email-masked] <mailto:[email-masked]>;
>>>             Dolganow, Andrew (Andrew); [email-masked]
>>>             <mailto:[email-masked]>; Linda Dunbar
>>>             *Subject:* Re: [sfc] NSH context headers: fixed/tlv____
>>>
>>>             ____
>>>
>>>             ____
>>>
>>>                 On Nov 19, 2015, at 9:28 PM, Qin Wu
>>>                 <[email-masked] <mailto:[email-masked]>>
>>>                 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____
>>>
>>>             ____
>>>
>>>
>>>             https://www.ietf.org/mailman/listinfo/sfc____
>>>
>>>         __ __
>>>
>>>     __ __
>>>
>>
>>

---

From: Dave Dolson <[email-masked]>
Date: Thu, 3 Dec 2015 16:57:38 +0000

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:[email-masked]] On Behalf Of David Melman
Sent: Thursday, December 03, 2015 9:54 AM
To: [email-masked]
Subject: Re: [sfc] NSH context headers: fixed/tlv

David

To: [email-masked]<mailto:[email-masked]>; Dave Dolson; Carlos Pignataro (cpignata); Bottorff, Paul

Dear all,

Regards, Walter

Hi Dave, all,

Cheers,
Med

-Dave

Hi, Paul B.,

Hi Carlos:

More on this below,

Cheers,

Paul

Paul B.,

Please see inline.

Hi Paul Q.:

See inline,

Cheers,

Paul

Hi, Paul B.,

Hi Paul and Andew:

See below.

Please no translations!

— Carlos.

Thanks!

— Carlos.

Thanks,

— Carlos.

Cheers,

Paul

Hi Andy,

Please see below.

Thanks
Paul

Cheers,
Andy

Cheers,

Paul

Hi, Andrew and Paul:

Thanks,
Paul

---

From: "Haeffner, Walter, Vodafone DE" <[email-masked]>
Date: Thu, 3 Dec 2015 19:20:51 +0000

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:[email-masked]] Im Auftrag von Dave Dolson
Gesendet: Donnerstag, 3. Dezember 2015 17:58
An: David Melman; [email-masked]
Betreff: Re: [sfc] NSH context headers: fixed/tlv

-Dave

From: sfc [mailto:[email-masked]] On Behalf Of David Melman
Sent: Thursday, December 03, 2015 9:54 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] NSH context headers: fixed/tlv

David

Dear all,

Regards, Walter

Hi Dave, all,

Cheers,
Med

-Dave

Hi, Paul B.,

Hi Carlos:

More on this below,

Cheers,

Paul

Paul B.,

Please see inline.

Hi Paul Q.:

See inline,

Cheers,

Paul

Hi, Paul B.,

Hi Paul and Andew:

See below.

Please no translations!

— Carlos.

Thanks!

— Carlos.

Thanks,

— Carlos.

Cheers,

Paul

Hi Andy,

Please see below.

Thanks
Paul

Cheers,
Andy

Cheers,

Paul

Hi, Andrew and Paul:

Thanks,
Paul

---

From: "Bottorff, Paul" <[email-masked]>
Date: Thu, 3 Dec 2015 19:20:08 +0000

Hi David:

I’d like to understand a little better what the real hardware requirement is for fixed headers.

It seems like we can’t have a fixed offset to the NSH header from the start of the frame.
-If we have an Ethernet layer we have 4 different tags which are Typed with an Ethertype and have different implicit lengths. These are TV encoding with implicit length.
-If we have an MPLS label stack or an MPLS segment route stack the number of labels in the MPLS stack will determine the size of the MPLS header. For MPLS this would typically be determined by the context identified by the first label in the stack. In effect the first label identifies an implicit length for the stack. In an MPLS Segment Route stack we would have variable lengths depending on the number of segments and where we are in the stack. In either case the important thing is that we know the offset to the top label.
-If we have one of the NVO3 encapsulations then we will have a variety layered encapsulations.

I think what we need for hardware is:
1)the ability to easily parse over the NSH header;
2)the ability to find the fields we need for switching (in hardware and software) at fixed offsets from the start of the NSH header.
It seems the Length field of the NSH header provides an easy method to parse over the NSH header regardless the internal organization of the header.
It seems the requirement of the fixed header is actually to have meta-data located at fixed offsets from the beginning of the NSH header.

So what is the actual requirement under this fixed length discussion?

Cheers,

Paul

From: sfc [mailto:[email-masked]] On Behalf Of David Melman
Sent: Thursday, December 03, 2015 6:54 AM
To: [email-masked]
Subject: Re: [sfc] NSH context headers: fixed/tlv

David

Dear all,

Regards, Walter

Hi Dave, all,

Cheers,
Med

-Dave

Hi, Paul B.,

Hi Carlos:

More on this below,

Cheers,

Paul

Paul B.,

Please see inline.

Hi Paul Q.:

See inline,

Cheers,

Paul

Hi, Paul B.,

Hi Paul and Andew:

See below.

Please no translations!

— Carlos.

Thanks!

— Carlos.

Thanks,

— Carlos.

Cheers,

Paul

Hi Andy,

Please see below.

Thanks
Paul

Cheers,
Andy

Cheers,

Paul

Hi, Andrew and Paul:

Thanks,
Paul

---

From: Eric Gray <[email-masked]>
Date: Thu, 3 Dec 2015 19:25:51 +0000

Or are you referring to “implicit length” based on type in a “Type Value” encoding?

From: sfc [mailto:[email-masked]] On Behalf Of Bottorff, Paul
Sent: Thursday, December 03, 2015 2:20 PM
To: David Melman; [email-masked]
Subject: Re: [sfc] NSH context headers: fixed/tlv

Hi David:

Cheers,

Paul

David

Dear all,

Regards, Walter

Hi Dave, all,

Cheers,
Med

-Dave

Hi, Paul B.,

Hi Carlos:

More on this below,

Cheers,

Paul

Paul B.,

Please see inline.

Hi Paul Q.:

See inline,

Cheers,

Paul

Hi, Paul B.,

Hi Paul and Andew:

See below.

Please no translations!

— Carlos.

Thanks!

— Carlos.

Thanks,

— Carlos.

Cheers,

Paul

Hi Andy,

Please see below.

Thanks
Paul

Cheers,
Andy

Cheers,

Paul

Hi, Andrew and Paul:

Thanks,
Paul

---

From: "Bottorff, Paul" <[email-masked]>
Date: Thu, 3 Dec 2015 19:31:35 +0000

Hi Eric:

I’m referring to implicit length based on the EtherType. The actual encoding is Type-Value not Type-Length-Value where the Length is implicit from the Type. In the MPLS case the Length is frequently implicit from the context determined by the first label. We could consider this also a TV encode were the label determines the context which also determines the type.

Cheers,

Paul

From: Eric Gray [mailto:[email-masked]]
Sent: Thursday, December 03, 2015 11:26 AM
To: Bottorff, Paul; David Melman; [email-masked]
Subject: RE: [sfc] NSH context headers: fixed/tlv

From: sfc [mailto:[email-masked]] On Behalf Of Bottorff, Paul
Sent: Thursday, December 03, 2015 2:20 PM
To: David Melman; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] NSH context headers: fixed/tlv

Hi David:

Cheers,

Paul

David

Dear all,

Regards, Walter

Hi Dave, all,

Cheers,
Med

-Dave

Hi, Paul B.,

Hi Carlos:

More on this below,

Cheers,

Paul

Paul B.,

Please see inline.

Hi Paul Q.:

See inline,

Cheers,

Paul

Hi, Paul B.,

Hi Paul and Andew:

See below.

Please no translations!

— Carlos.

Thanks!

— Carlos.

Thanks,

— Carlos.

Cheers,

Paul

Hi Andy,

Please see below.

Thanks
Paul

Cheers,
Andy

Cheers,

Paul

Hi, Andrew and Paul:

Thanks,
Paul

---

From: Eric Gray <[email-masked]>
Date: Thu, 3 Dec 2015 19:34:48 +0000

Got it.  Thanks…

From: Bottorff, Paul [mailto:[email-masked]]
Sent: Thursday, December 03, 2015 2:32 PM
To: Eric Gray; David Melman; [email-masked]
Subject: RE: [sfc] NSH context headers: fixed/tlv
Importance: High

Hi Eric:

Cheers,

Paul

From: Eric Gray [mailto:[email-masked]]
Sent: Thursday, December 03, 2015 11:26 AM
To: Bottorff, Paul; David Melman; [email-masked]<mailto:[email-masked]>
Subject: RE: [sfc] NSH context headers: fixed/tlv

Hi David:

Cheers,

Paul

David

Dear all,

Regards, Walter

Hi Dave, all,

Cheers,
Med

-Dave

Hi, Paul B.,

Hi Carlos:

More on this below,

Cheers,

Paul

Paul B.,

Please see inline.

Hi Paul Q.:

See inline,

Cheers,

Paul

Hi, Paul B.,

Hi Paul and Andew:

See below.

Please no translations!

— Carlos.

Thanks!

— Carlos.

Thanks,

— Carlos.

Cheers,

Paul

Hi Andy,

Please see below.

Thanks
Paul

Cheers,
Andy

Cheers,

Paul

Hi, Andrew and Paul:

Thanks,
Paul

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Thu, 3 Dec 2015 19:41:32 +0000

On Dec 2, 2015, at 9:18 PM, Andrew G. Malis <[email-masked]<mailto:[email-masked]>> wrote:

Dave,

On Wed, Dec 2, 2015 at 1:23 PM, Dave Dolson <[email-masked]<mailto:[email-masked]>> wrote:
So as I see it, Type 2 is the generic one and Type 1 is an optimization for special cases.

That’s exactly as I see it as well (stated in an earlier email in this discussion).

"generic" does not mean that it makes sense to mandate.  Quite the opposite in many ways.  I mentioned earlier in this thread: the use of TLV in dataplane protocols has not been a resounding success.

So, while I understand the allure of generic, in practical terms -- both hardware _and_ software -- implementations need to support a much more complex protocol.  This isn't to say we shouldn't have the option for such but mandating such is will likely yield a paradoxical outcome: the very appealing generic nature of the TLV results in complexity that reduce the actual appeal of the protocol.

The simplest option allows everyone to have a baseline and get implementations out the door.  This might sound odd, but lowest common denominator is exactly how we encourage development, deployment and interop.

---

From: Dave Dolson <[email-masked]>
Date: Thu, 3 Dec 2015 19:47:54 +0000

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; [email-masked]
Subject: AW: [sfc] NSH context headers: fixed/tlv

Regards,
Walter

-Dave

David

Dear all,

Regards, Walter

Hi Dave, all,

Cheers,
Med

-Dave

Hi, Paul B.,

Hi Carlos:

More on this below,

Cheers,

Paul

Paul B.,

Please see inline.

Hi Paul Q.:

See inline,

Cheers,

Paul

Hi, Paul B.,

Hi Paul and Andew:

See below.

Please no translations!

— Carlos.

Thanks!

— Carlos.

Thanks,

— Carlos.

Cheers,

Paul

Hi Andy,

Please see below.

Thanks
Paul

Cheers,
Andy

Cheers,

Paul

Hi, Andrew and Paul:

Thanks,
Paul

---

From: Ron Parker <[email-masked]>
Date: Thu, 3 Dec 2015 19:51:46 +0000

I understand and agree that TLV has its overhead and that type 1 (-ish) could be a preferable alternative in some cases.   However, as a former hardware designer, I’m not completely in agreement on the hardware-driven rationale – hardware is more capable than implied and incremental gate allocation based on increased complexity is a well understood tradeoff.   All that said, I’m not arguing against a non-TLV alternative, but I do think it could/should have a bit more flexibility and a bit more self-description encoded on the wire.     As I’ve requested previously on this thread, I would like to see NSH type 1 supporting a metadata length field (in 4 or 8 byte increments with 0 explicitly supported) and a schema id field (with interpretation of that schema id being a control plane and/or provisioning matter).

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of Paul Quinn (paulq)
Sent: Thursday, December 3, 2015 2:42 PM
To: Andrew G. Malis <[email-masked]>
Cc: Carlos Pignataro (cpignata) <[email-masked]>; [email-masked]; Dave Dolson <[email-masked]>; Bottorff, Paul <[email-masked]>
Subject: Re: [sfc] NSH context headers: fixed/tlv

Dave,

---

From: "Bottorff, Paul" <[email-masked]>
Date: Thu, 3 Dec 2015 19:54:08 +0000

Hi Paul:

The way NSH is currently specified we have two separate incompatible formats which are fixed or TLV. I’m opposed to having two different formats when it is possible to have a single format which accommodates all the requirements. It seems to me your argument is simply a way to eliminate the TLV option by making it a loss leader in the market.

Cheers,

Paul

From: Paul Quinn (paulq) [mailto:[email-masked]]
Sent: Thursday, December 03, 2015 11:42 AM
To: Andrew G. Malis
Cc: Dave Dolson; Carlos Pignataro (cpignata); Bottorff, Paul; [email-masked]
Subject: Re: [sfc] NSH context headers: fixed/tlv

Dave,

---

From: "Haeffner, Walter, Vodafone DE" <[email-masked]>
Date: Thu, 3 Dec 2015 19:59:28 +0000

Thanks for your response. 

Right. SFF only requires an RSP-ID and the SF-Index for forwarding. The metadata are parsed by the SF or SF-proxy and processed by the SF.

-----Ursprüngliche Nachricht-----
Von: Dave Dolson [mailto:[email-masked]] 
Gesendet: Donnerstag, 3. Dezember 2015 20:48
An: Haeffner, Walter, Vodafone DE; David Melman; [email-masked]
Betreff: Re: [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.

I don't understand your third statement. Dave, may you please explain in some more detail?

Regards,
Walter

Actually, it would be possible to mandate, "An SFF MUST support any value (0-255) of MD type."

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

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

Dear all,

Regards, Walter

Hi Dave, all,

I'm still in favor of having MD#2 be MUST.

Cheers,
Med

De : sfc [mailto:[email-masked]] 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; [email-masked]<mailto:[email-masked]> 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.

Also, for many users who don't use metadata, Type 2 is more efficient.

-Dave

Hi, Paul B.,

Hi Carlos:

More on this below,

Cheers,

Paul

Paul B.,

Please see inline.

Hi Paul Q.:

See inline,

Cheers,

Paul

Hi, Paul B.,

Hi Paul and Andew:

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.

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.

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.

Please no translations!

- Carlos.

Thanks!

- Carlos.

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

Hi Andy,

Please see below.

Thanks
Paul

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

Cheers,

Paul

Hi, Andrew and Paul:

Thanks,
Paul

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 3 Dec 2015 20:03:52 +0000

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" <[email-masked]
on behalf of [email-masked]> wrote:

>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.
>
>
>
>
>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
>
>Actually, it would be possible to mandate, ³An SFF MUST support any value
>(0-255) of MD type.²
>
>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
>
>
>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
>
>To: [email-masked]<mailto:[email-masked]>;
>Dave Dolson; Carlos Pignataro (cpignata); Bottorff, Paul
>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:[email-masked]] Im Auftrag von
>[email-masked]<mailto:[email-masked]>
>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
>
>> 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.
>Also, for many users who don¹t use metadata, Type 2 is more efficient.
>
>On Dec 1, 2015, at 5:57 PM, Bottorff, Paul
><[email-masked]<mailto:[email-masked]>> wrote:
>
>Hi Carlos:
>
>More on this below,
>
>Cheers,
>
>Paul
>
>On Dec 1, 2015, at 5:12 PM, Bottorff, Paul
><[email-masked]<mailto:[email-masked]>> wrote:
>
>Hi Paul Q.:
>
>See inline,
>
>Cheers,
>
>Paul
>
>On Dec 1, 2015, at 4:45 PM, Bottorff, Paul
><[email-masked]<mailto:[email-masked]>> 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.
>
>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.
>
>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.
>
>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.
>
>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
>
><[email-masked]<mailto:[email-masked]>> wrote:
>
>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
>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.
>
>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.
>
>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.
>
>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
>
>
><[email-masked]<mailto:[email-masked]>> 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.
>
>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.
>
>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
>Cc: [email-masked]<mailto:[email-masked]>; Dolganow, Andrew
>(Andrew); [email-masked]<mailto:[email-masked]>; Linda Dunbar
><[email-masked]<mailto:[email-masked]>> wrote:
>
>Hi, Andrew and Paul:
>That's the balance that we decided to strike and it seems to be
>reasonable and well accepted.
>
>Thanks,
>Paul
>
>

---

From: Jesse Gross <[email-masked]>
Date: Thu, 3 Dec 2015 20:16:10 +0000

On 12/3/15, 11:41 AM, "sfc on behalf of Paul Quinn (paulq)" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Dave,

Speaking as one of the main authors of Open vSwitch, I strongly disagree with the implication that the use of a set of 4 fixed fields is a design that is appealing to software. The benefits of flexibility vastly outweigh the relatively minimal additional implementation time.

Whether or not TLVs are implemented in practice is not an inherent property of TLVs. It entirely depends on whether people think they are a useful feature when the protocol initially starts to see some adoption or whether they view it as a secondary and optional mechanism. If the TLVs are not a core mechanism on day 1 then nobody will implement them and in the future everybody will “know” that TLV based extensions are unusable.

---

From: Sumandra Majee <[email-masked]>
Date: Thu, 3 Dec 2015 20:50:53 +0000

On 12/3/15, 11:47 AM, "sfc on behalf of Dave Dolson" <[email-masked]

>make a forwarding decision. SFFs don't need metadata or start of inner

That is a very broad statement and I don¹t agree with that. If SFF wants
to look at flowid, or at another contextual information to skip a portion
of chain then that would be required. Furthermore it will perhaps restrict
many other potential optimization and applications. SFF is a logical
entity and can be implemented in software with highly programmable hooks
or it can be a dumb next hop lookup engine.

---

From: "Haeffner, Walter, Vodafone DE" <[email-masked]>
Date: Thu, 3 Dec 2015 21:21:21 +0000

Hi Sumandra,

Thanks for your feedback. From my point of view it would make some sense if the WG would elaborate more details on the actual forwarding requirements. Some would say use NSH SFP but the WG allowed that a SFP must not uniquely support a FW decision. Therefore the notion of a RSP. For sure we could  also use a SFP-ID plus some "SFP distinguisher" to ensure appropriate forwarding. 

When you talk about a flow-id, do you mean the original naked user generated L2/L3 flow before entering the SFC overlay (tunnel) system? If yes, how does this information contribute to a constrained SFC overlay forwarding? We would use the flow entries and try to generate something like an "SFC entropy-ID" (not to say label) as a "SFP distinguisher" but will this data really include info on constrained SFC forwarding? 

Until now I thought a SFF first is a simple FW engine which may be extended to become a classifier. I've seen the intelligence located more in the SF. But well, it may be worth to think about your view that a SFF may have some more functionality. 

Best regards,
Walter

-----Ursprüngliche Nachricht-----
Von: Sumandra Majee [mailto:[email-masked]] 
Gesendet: Donnerstag, 3. Dezember 2015 21:51
An: Dave Dolson; Haeffner, Walter, Vodafone DE; David Melman; [email-masked]
Betreff: Re: [sfc] NSH context headers: fixed/tlv

>make a forwarding decision. SFFs don't need metadata or start of inner 

That is a very broad statement and I don¹t agree with that. If SFF wants to look at flowid, or at another contextual information to skip a portion of chain then that would be required. Furthermore it will perhaps restrict many other potential optimization and applications. SFF is a logical entity and can be implemented in software with highly programmable hooks or it can be a dumb next hop lookup engine.

---

From: Dave Dolson <[email-masked]>
Date: Thu, 3 Dec 2015 21:25:20 +0000

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:[email-masked]] 
Sent: Thursday, December 03, 2015 3:04 PM
To: Dave Dolson; Haeffner, Walter, Vodafone DE; David Melman; [email-masked]
Subject: Re: [sfc] NSH context headers: fixed/tlv

Hi Dave,

Jim

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 3 Dec 2015 21:28:01 +0000

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 <[email-masked]> wrote:
> 
> 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
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 3 Dec 2015 16:33:28 -0500

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

---

From: "Bottorff, Paul" <[email-masked]>
Date: Thu, 3 Dec 2015 21:35:38 +0000

Hi Walter and Sumandra:

It seems that the committee is focused on a single transport mechanism based on forwarding using the SPF-ID and Service Index (together forming a new address space). The current transport arrangement based on incrementing (or decrementing) SI has lots of flaws which are already surfacing in discussions.

The SPF-ID and SI are not required for a number of the other chain forwarding mechanisms including MAC Chaining, MPLS Chaining, MPLS Segment Route Chaining and VID Chaining. For these the SPF-ID/SI fields should be optional.

Cheers,

Paul

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Haeffner, Walter, Vodafone DE
Sent: Thursday, December 03, 2015 1:21 PM
To: Sumandra Majee; Dave Dolson; David Melman; [email-masked]
Subject: Re: [sfc] NSH context headers: fixed/tlv

Hi Sumandra,

Best regards,
Walter

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 3 Dec 2015 16:51:04 -0500

Paul, you describe the NSH header SFP-ID/SFP-Index mechanism as a
transport.  I do not think that is a reasoanble characterization.

The goal, as described in the charter and the architecture, is for the
NSH header to provide a transport-independent mechanism for doing
service chain forwarding and carrying metadata.
The point is to having something that provides interoperation under the
various transports we all like.
The architecture is clear that were appropriate one may carry NSH and
use transport based mechanisms for the SFF forwarding.

NSH has to be encapsulated in a transport (Ethernet, Eth+IP, ETH+MPLS, 
... in order to be carried.  So I really think this is a 
mis-characterization.

Yours,
Joel

On 12/3/15 4:35 PM, Bottorff, Paul wrote:
> Hi Walter and Sumandra:
>
> It seems that the committee is focused on a single transport
> mechanism based on forwarding using the SPF-ID and Service Index
> (together forming a new address space). The current transport
> arrangement based on incrementing (or decrementing) SI has lots of
> flaws which are already surfacing in discussions.
>
> The SPF-ID and SI are not required for a number of the other chain
> forwarding mechanisms including MAC Chaining, MPLS Chaining, MPLS
> Segment Route Chaining and VID Chaining. For these the SPF-ID/SI
> fields should be optional.
>
> Cheers,
>
> Paul
>
> -----Original Message----- From: sfc [mailto:[email-masked]] On
> Behalf Of Haeffner, Walter, Vodafone DE Sent: Thursday, December 03,
> 2015 1:21 PM To: Sumandra Majee; Dave Dolson; David Melman;
> [email-masked] Subject: Re: [sfc] NSH context headers: fixed/tlv
>
> Hi Sumandra,
>
> Thanks for your feedback. From my point of view it would make some
> sense if the WG would elaborate more details on the actual forwarding
> requirements. Some would say use NSH SFP but the WG allowed that a
> SFP must not uniquely support a FW decision. Therefore the notion of
> a RSP. For sure we could  also use a SFP-ID plus some "SFP
> distinguisher" to ensure appropriate forwarding.
>
> When you talk about a flow-id, do you mean the original naked user
> generated L2/L3 flow before entering the SFC overlay (tunnel) system?
> If yes, how does this information contribute to a constrained SFC
> overlay forwarding? We would use the flow entries and try to generate
> something like an "SFC entropy-ID" (not to say label) as a "SFP
> distinguisher" but will this data really include info on constrained
> SFC forwarding?
>
> Until now I thought a SFF first is a simple FW engine which may be
> extended to become a classifier. I've seen the intelligence located
> more in the SF. But well, it may be worth to think about your view
> that a SFF may have some more functionality.
>
> Best regards, Walter
>
> -----Ursprüngliche Nachricht----- Von: Sumandra Majee
> [mailto:[email-masked]] Gesendet: Donnerstag, 3. Dezember 2015 21:51
> An: Dave Dolson; Haeffner, Walter, Vodafone DE; David Melman;
> [email-masked] Betreff: Re: [sfc] NSH context headers: fixed/tlv
>
>
>
> On 12/3/15, 11:47 AM, "sfc on behalf of Dave Dolson"
> <[email-masked] on behalf of [email-masked]> 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.
>
> That is a very broad statement and I don¹t agree with that. If SFF
> wants to look at flowid, or at another contextual information to skip
> a portion of chain then that would be required. Furthermore it will
> perhaps restrict many other potential optimization and applications.
> SFF is a logical entity and can be implemented in software with
> highly programmable hooks or it can be a dumb next hop lookup
> engine.
>>
>>
>>
>
> _______________________________________________ sfc mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/sfc
>
> _______________________________________________ sfc mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/sfc
>

---

From: "Bottorff, Paul" <[email-masked]>
Date: Thu, 3 Dec 2015 21:50:26 +0000

Hi Jesse:

Agreed.

There is no technical reason for multiple formats, as we now have. We should strive for a single format which can fill all of our needs. This will produce the fasted product development and broadest market acceptance.

Cheers,

Paul

From: Jesse Gross [mailto:[email-masked]]
Sent: Thursday, December 03, 2015 12:16 PM
To: Paul Quinn (paulq); Andrew G. Malis
Cc: Carlos Pignataro (cpignata); [email-masked]; Dave Dolson; Bottorff, Paul
Subject: Re: [sfc] NSH context headers: fixed/tlv

Dave,

---

From: "Bottorff, Paul" <[email-masked]>
Date: Thu, 3 Dec 2015 21:56:03 +0000

Hi Joel:

We disagree.

The use of SFP-ID/SI is no different than the use MAC switching or MPLS label swapping to determine the next chain hop. Either they are all transports or they are all not transports.

Cheers,

Paul

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Thursday, December 03, 2015 1:51 PM
To: Bottorff, Paul; [email-masked]
Subject: Re: [sfc] NSH context headers: fixed/tlv

Paul, you describe the NSH header SFP-ID/SFP-Index mechanism as a transport.  I do not think that is a reasoanble characterization.

The goal, as described in the charter and the architecture, is for the NSH header to provide a transport-independent mechanism for doing service chain forwarding and carrying metadata.
The point is to having something that provides interoperation under the various transports we all like.
The architecture is clear that were appropriate one may carry NSH and use transport based mechanisms for the SFF forwarding.

NSH has to be encapsulated in a transport (Ethernet, Eth+IP, ETH+MPLS, ... in order to be carried.  So I really think this is a mis-characterization.

Yours,
Joel

On 12/3/15 4:35 PM, Bottorff, Paul wrote:
> Hi Walter and Sumandra:
>
> It seems that the committee is focused on a single transport mechanism 
> based on forwarding using the SPF-ID and Service Index (together 
> forming a new address space). The current transport arrangement based 
> on incrementing (or decrementing) SI has lots of flaws which are 
> already surfacing in discussions.
>
> requirements. Some would say use NSH SFP but the WG allowed that a SFP 
> must not uniquely support a FW decision. Therefore the notion of a 
> RSP. For sure we could  also use a SFP-ID plus some "SFP 
>> 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.
>
> SFF is a logical entity and can be implemented in software with highly 
> programmable hooks or it can be a dumb next hop lookup engine.
>>
>>
>>
>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 3 Dec 2015 22:01:36 +0000

Hi Paul,

Sent from my iPhone

> On Dec 3, 2015, at 4:37 PM, Bottorff, Paul <[email-masked]> wrote:
> 
> Hi Walter and Sumandra:
> 

Which specific flaws are you referring to ?

> The SPF-ID and SI are not required for a number of the other chain forwarding mechanisms including MAC Chaining, MPLS Chaining, MPLS Segment Route Chaining and VID Chaining. For these the SPF-ID/SI…

As we are not chartered to address these then we need not worry whether SPI/SI is optional or not.

Jim

---

From: "Haeffner, Walter, Vodafone DE" <[email-masked]>
Date: Thu, 3 Dec 2015 22:20:55 +0000

Hi Paul,

Thanks for your immediate response. I am not sure it the SFP-ID + SF-ID is sufficient.  My view is that I need the RSP-ID + SF-ID to make FW unique. Use SF-ID to control potential loops and termination. Anything else?
For me, SFP is something between a SFC and a real path  (RSP) simply indicating a set of possible associated RSPs. What is the "magic" isolating the right RSP? I think, here we have multiple possibilities.

We also could define a path differently. Assume some SF-VMs behind a LB. I could argue the SFP describes the set of all paths to all the SF-VMs and some RSP is one out of many options. If I would consider the construct LB + SF-VMs to be a SF-Group the path would terminate at the LB and SFP and RSP would be the same. 

Cheers,
Walter

-----Ursprüngliche Nachricht-----
Von: Bottorff, Paul [mailto:[email-masked]] 
Gesendet: Donnerstag, 3. Dezember 2015 22:36
An: Haeffner, Walter, Vodafone DE; Sumandra Majee; Dave Dolson; David Melman; [email-masked]
Betreff: RE: [sfc] NSH context headers: fixed/tlv

Hi Walter and Sumandra:

Cheers,

Paul

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Haeffner, Walter, Vodafone DE
Sent: Thursday, December 03, 2015 1:21 PM
To: Sumandra Majee; Dave Dolson; David Melman; [email-masked]
Subject: Re: [sfc] NSH context headers: fixed/tlv

Hi Sumandra,

Best regards,
Walter

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Thu, 3 Dec 2015 22:27:48 +0000

Hi Jim,

We had a long discussion on this until you opined with your chair hat. Primarily, SI is being overloaded, at least as reasoned in different threads, to perform: OAM, forwarding, TTL.

That does not even include the other key issue of SF modifying the SI and SFF forwarding based on that value. It is ironical that an architecture component called "SFF", with the last 'F' for forwarding, is defined but it does not make the complete forwarding decision. This needs to be fixed.

Surendra.

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Thursday, December 03, 2015 2:02 PM
To: Bottorff, Paul <[email-masked]>
Cc: David Melman <[email-masked]>; Haeffner, Walter, Vodafone DE <[email-masked]>; Sumandra Majee <[email-masked]>; Dave Dolson <[email-masked]>; [email-masked]
Subject: Re: [sfc] NSH context headers: fixed/tlv

Hi Paul,

Sent from my iPhone

Jim

>> I don't believe SFFs need to parse past the start of the NSH header

---

From: "Haeffner, Walter, Vodafone DE" <[email-masked]>
Date: Thu, 3 Dec 2015 22:29:42 +0000

Yes Paul,

You could argue this way. But to my understanding the objective is to have a mechanism describing FW in an abstract, topological SFC plane and subsequently map this - probably stepwise - onto the physical plane. That is, I somehow need a pointer interconnecting abstract and physical description. 

Joel, you agree on this reasoning?

Cheers, Walter

-----Ursprüngliche Nachricht-----
Von: sfc [mailto:[email-masked]] Im Auftrag von Bottorff, Paul
Gesendet: Donnerstag, 3. Dezember 2015 22:56
An: Joel M. Halpern; [email-masked]
Betreff: Re: [sfc] NSH context headers: fixed/tlv

Hi Joel:

We disagree.

Cheers,

Paul

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Thursday, December 03, 2015 1:51 PM
To: Bottorff, Paul; [email-masked]
Subject: Re: [sfc] NSH context headers: fixed/tlv

Yours,
Joel

---

From: "Bottorff, Paul" <[email-masked]>
Date: Thu, 3 Dec 2015 22:30:35 +0000

Hi Walter:

See below,

Cheers,

Paul

-----Original Message-----
From: Haeffner, Walter, Vodafone DE [mailto:[email-masked]] 
Sent: Thursday, December 03, 2015 2:21 PM
To: Bottorff, Paul; Sumandra Majee; Dave Dolson; David Melman; [email-masked]
Subject: AW: [sfc] NSH context headers: fixed/tlv

Hi Paul,

PB>Walter, I believe I'm in agreement with your outlook. In particular, I think a path identifies a series of SFs where each SF may be have many instances. I look at the LB + SF-VMs as a single SF (each SF in my mind is a group). I could say SF-Group for clarity, however the SFP does not really know if we have a single SF instance or a group so I prefer to just say SF.
PB>Of course the LB which may or may not be integrated with the SFF may need some of the meta-data beyond the SFP-ID/SI.

Cheers,
Walter

-----Ursprüngliche Nachricht-----
Von: Bottorff, Paul [mailto:[email-masked]] 
Gesendet: Donnerstag, 3. Dezember 2015 22:36
An: Haeffner, Walter, Vodafone DE; Sumandra Majee; Dave Dolson; David Melman; [email-masked]
Betreff: RE: [sfc] NSH context headers: fixed/tlv

Hi Walter and Sumandra:

Cheers,

Paul

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Haeffner, Walter, Vodafone DE
Sent: Thursday, December 03, 2015 1:21 PM
To: Sumandra Majee; Dave Dolson; David Melman; [email-masked]
Subject: Re: [sfc] NSH context headers: fixed/tlv

Hi Sumandra,

Best regards,
Walter

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 3 Dec 2015 17:40:24 -0500

That (particularly with the stepwise) matches my understanding and 
expectation.

Yours,
Joel

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Thu, 3 Dec 2015 22:54:51 +0000

Walter,

Inline.

Surendra.

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Haeffner, Walter, Vodafone DE
Sent: Thursday, December 03, 2015 1:21 PM
To: Sumandra Majee <[email-masked]>; Dave Dolson <[email-masked]>; David Melman <[email-masked]>; [email-masked]
Subject: Re: [sfc] NSH context headers: fixed/tlv

Hi Sumandra,

Thanks for your feedback. From my point of view it would make some sense if the WG would elaborate more details on the actual forwarding requirements. Some would say use NSH SFP but the WG allowed that a SFP must not uniquely support a FW decision. Therefore the notion of a RSP. For sure we could  also use a SFP-ID plus some "SFP distinguisher" to ensure appropriate forwarding. 
SK> The way I see it, the service path header (bits 32-63 of NSH) is a service forwarding context. What goes in this is defined by the control plane. SFFs use this to forward on it and it remains opaque to the SFs. NSH goes a step further in breaking this down into SPI and SI. This makes it easy to think about traffic flowing through a service chain as well as to implement it.

Until now I thought a SFF first is a simple FW engine which may be extended to become a classifier.
SK> SFF is an abstract function defined for forwarding (steering on a service chain as well as forwarding at the end of a chain). Whether it is co-located with an SF in some tangible network element, is not described anywhere, unless I missed it. That is left open for use cases.

I've seen the intelligence located more in the SF. But well, it may be worth to think about your view that a SFF may have some more functionality. 

Best regards,
Walter

---

From: "Bottorff, Paul" <[email-masked]>
Date: Thu, 3 Dec 2015 23:04:26 +0000

Hi Walter:

See below,

Cheers,

Paul

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Thursday, December 03, 2015 2:40 PM
To: Haeffner, Walter, Vodafone DE; Bottorff, Paul; Joel M. Halpern; [email-masked]
Subject: Re: AW: [sfc] NSH context headers: fixed/tlv

That (particularly with the stepwise) matches my understanding and expectation.

Yours,
Joel

> You could argue this way. But to my understanding the objective is to have a mechanism describing FW in an abstract, topological SFC plane and subsequently map this - probably stepwise - onto the p…

PB>I agree with this outlook. For MAC Chaining this abstraction of the SFP is addresses by a locally assigned MAC address called a Segment MAC as described in:  https://datatracker.ietf.org/doc/draft-fedyk-sfc-mac-chain/  .
If you have an LB, then the MAC Segment address is for the entire LB+SF-VMs group. A variety of other abstract reduction are also possible.

PB>For and MPLS or Segment Route chaining a similar abstraction is made from the label.

PB>When looking at the MAC and MPLS chaining systems please keep in mind that they will probably be carried over an NVO3 encapsulation (the MAC or MPLS stack used for chain forwarding is the inside (or encapsulated) MAC). For MPLS an MPLS stacks could either be encapsulated on the inside of an NVO3 encapsulation or could be the second MPLS stack within an MPLS outer transport.

PB>All for these methods build an abstract forwarding model between SFs using SFFs and LBs.

>> highly programmable hooks or it can be a dumb next hop lookup engine.
>>>
>>>
>>>
>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 3 Dec 2015 18:25:46 -0500

Paul, there is one word that you seem to not consider important.  "A". 
We are supposed to standardize a mechanism.  Not all the transports.

Yours,
Joel

---

From: "Bottorff, Paul" <[email-masked]>
Date: Thu, 3 Dec 2015 23:35:38 +0000

Hi Joel:

I don't see that "A" stands for one and only one. "A" says at least one. It also stands in contradiction to not standardizing transport mechanisms. 

Cheers,

Paul

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Thursday, December 03, 2015 3:26 PM
To: Bottorff, Paul; Haeffner, Walter, Vodafone DE; [email-masked]
Subject: Re: [sfc] NSH context headers: fixed/tlv

Yours,
Joel

On 12/3/15 6:04 PM, Bottorff, Paul wrote:
>>> -----Original Message----- From: sfc [mailto:[email-masked]] 
>>> On Behalf Of Haeffner, Walter, Vodafone DE Sent: Thursday, December 
>>> 03,
>>> sense if the WG would elaborate more details on the actual 
>>> forwarding requirements. Some would say use NSH SFP but the WG 
>>> allowed that a SFP must not uniquely support a FW decision. 
>>> Therefore the notion of a RSP. For sure we could  also use a SFP-ID 
>>> plus some "SFP distinguisher" to ensure appropriate forwarding.
>>>
>>> overlay forwarding? We would use the flow entries and try to 
>>> generate something like an "SFC entropy-ID" (not to say label) as a 
>>> "SFP distinguisher" but will this data really include info on 
>>> constrained SFC forwarding?
>>>
>>> wants to look at flowid, or at another contextual information to 
>>> skip a portion of chain then that would be required. Furthermore it 
>>> will perhaps restrict many other potential optimization and applications.

---

From: Sumandra Majee <[email-masked]>
Date: Fri, 4 Dec 2015 04:00:05 +0000

Paul,

Are you suggesting that WG standardize a set of transport mechanism to
carry NSH? 
And are you suggesting that there be different SFF forwarding logic for
each transport mechanism that is not based on SFF header exclusively?

Forgive me if I haven’t got this right, this thread has been rather long
with many conversations.

On 12/3/15, 3:35 PM, "sfc on behalf of Bottorff, Paul"
<[email-masked] on behalf of [email-masked]> wrote:

>Hi Joel:
>
>I don't see that "A" stands for one and only one. "A" says at least one.
>It also stands in contradiction to not standardizing transport
>mechanisms. 
>
>Cheers,
>
>Paul
>
>>> You could argue this way. But to my understanding the objective is to
>>>have a mechanism describing FW in an abstract, topological SFC plane
>>>and subsequently map this - probably stepwise - onto the physical
>>>plane. That is, I somehow need a pointer interconnecting abstract and
>>>physical description.
>>
>> PB>I agree with this outlook. For MAC Chaining this abstraction of the
>>SFP is addresses by a locally assigned MAC address called a Segment MAC
>>as described in: 
>>https://datatracker.ietf.org/doc/draft-fedyk-sfc-mac-chain/  .
>> If you have an LB, then the MAC Segment address is for the entire
>>LB+SF-VMs group. A variety of other abstract reduction are also possible.
>>
>> PB>When looking at the MAC and MPLS chaining systems please keep in
>>mind that they will probably be carried over an NVO3 encapsulation (the
>>MAC or MPLS stack used for chain forwarding is the inside (or
>>encapsulated) MAC). For MPLS an MPLS stacks could either be encapsulated
>>on the inside of an NVO3 encapsulation or could be the second MPLS stack
>>within an MPLS outer transport.
>>
>>> The use of SFP-ID/SI is no different than the use MAC switching or
>>>MPLS label swapping to determine the next chain hop. Either they are
>>>all transports or they are all not transports.
>>>
>>> Cheers,
>>>
>>> Paul
>>>

---

From: <[email-masked]>
Date: Fri, 4 Dec 2015 07:03:13 +0000

Hi David,

IMHO, what would bring more « adoption and compliance » is to have one single header not two. Having multiple flavors does not help for sure to increase interoperability for one.

From where I sit I don’t think this wg has a requirement that metadata is mandatory in every deployment, the typical number of context headers to be conveyed, the nature of the context headers, etc. All those aspects are deployment-specific.

We can speculate that MD#1 addresses the main use cases but none of the WG adopted use case I-Ds asks for a fixed header size approach of metadata (draft-ietf-sfc-dc-use-cases or draft-ietf-sfc-use-case-mobility).

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de David Melman
Envoyé : jeudi 3 décembre 2015 15:54
À : [email-masked]
Objet : Re: [sfc] NSH context headers: fixed/tlv

David

Dear all,

Regards, Walter

Hi Dave, all,

Cheers,
Med

-Dave

Hi, Paul B.,

Hi Carlos:

More on this below,

Cheers,

Paul

Paul B.,

Please see inline.

Hi Paul Q.:

See inline,

Cheers,

Paul

Hi, Paul B.,

Hi Paul and Andew:

See below.

Please no translations!

— Carlos.

Thanks!

— Carlos.

Thanks,

— Carlos.

Cheers,

Paul

Hi Andy,

Please see below.

Thanks
Paul

Cheers,
Andy

Cheers,

Paul

Hi, Andrew and Paul:

Thanks,
Paul