Subject: [sfc] NSH Service Index Decrement

From: James N Guichard <[email-masked]>
Date: Tue, 7 Feb 2017 19:24:07 +0000

Greetings WG,

At the recent interim meeting we discussed the current text on decrementing the service index in the NSH service path header. The existing text in section 3.3 of draft-ietf-sfc-nsh-10 reads:

"Service Index MUST be decremented by Service Functions or by SFC Proxy nodes after performing required services ..."

A request was made to be more specific and update the text as follows:

"Service index MUST be decremented by a value of 1 by Service Functions or by SFC Proxy nodes after performing required services ..."

Please provide comments on this change to the mailing list.

Thanks!

Jim & Joel

---

From: Dave Dolson <[email-masked]>
Date: Tue, 7 Feb 2017 19:34:33 +0000

I approve of this clarification.

From: sfc [mailto:[email-masked]] On Behalf Of James N Guichard
Sent: Tuesday, February 07, 2017 2:24 PM
To: [email-masked]
Subject: [sfc] NSH Service Index Decrement

Greetings WG,

Thanks!

Jim & Joel

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 7 Feb 2017 20:27:41 +0000

This is a useful clarification.

Thanks,

—
Carlos Pignataro, [email-masked]<mailto:[email-masked]>

“Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis."

On Feb 7, 2017, at 2:24 PM, James N Guichard <[email-masked]<mailto:[email-masked]>> wrote:

Greetings WG,

“Service Index MUST be decremented by Service Functions or by SFC Proxy nodes after performing required services …”

“Service index MUST be decremented by a value of 1 by Service Functions or by SFC Proxy nodes after performing required services …”

Thanks!

Jim & Joel

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 8 Feb 2017 10:39:34 -0000

Yes, thank you.
 
Clarity is Queen.
 
Adrian
 
From: sfc [mailto:[email-masked]] On Behalf Of Carlos Pignataro (cpignata)
Sent: 07 February 2017 20:28
To: James N Guichard
Cc: [email-masked]
Subject: Re: [sfc] NSH Service Index Decrement

Thanks,
 
—
Carlos Pignataro, [email-masked]

On Feb 7, 2017, at 2:24 PM, James N Guichard <[email-masked]> wrote:
 
Greetings WG,

 

 
Thanks!
 
Jim & Joel
 
_______________________________________________
sfc mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/sfc> https://www.ietf.org/mailman/listinfo/sfc

---

From: Eric C Rosen <[email-masked]>
Date: Wed, 8 Feb 2017 11:53:17 -0500

On 2/7/2017 2:24 PM, James N Guichard wrote:
> “Service index MUST be decremented *by a value of 1* by Service 
> Functions or by SFC Proxy nodes after performing required services …”
>

A couple of observations:

- The term "SFC Proxy node" is not defined in either the NSH draft or in 
RFC 7665.  I think the intention here is to say "SFC Proxy".

- Is the intention that the SI remain unchanged while the SF is 
operating on the packet, or is the intention only that the SI be 
decremented before the packet is delivered by the SF or SFC Proxy to an 
SFF?

I'd suggest either:

"An SF or SFC Proxy receiving an NSH-encapsulated packet MUST decrement 
the SI by 1 before delivering the packet to the next SFF"

or

"An SF or SFC Proxy receiving an NSH-encapsulated packet MUST decrement 
the SI by 1 before delivering the packet to the next SFF, but not until 
the SF has finished all its other processing of the packet"

depending upon which is intended.

I think an implication of these procedures is that an SI value of 1 is 
not valid.  If an SF gets an NSH packet with an SI of 1, the SF will 
decrement the SI (setting it to 0), send the packet to an SFF, and the 
SFF will discard it, because 0 is an invalid SI value.  Is that the 
intention?

The draft makes it clear (well, sort of) that an SFF should discard a 
packet with an SI of 0, but does not seem to say that an SF or SFC Proxy 
should discard a packet it receives with an SI of 0.  It would probably 
be a good idea to say that.

Some text in the draft (e.g., section 7.1) states than an SFF should 
discard a packet with an SI of zero, but other text in the draft (e.g., 
section 3.3) only says that an SFF should log an error if it sees an SI 
of zero.  It's probably best to change the text in 3.3. to say "SHOULD 
generate an error/log message and MUST discard the packet", or something 
similar.

---

From: Dave Dolson <[email-masked]>
Date: Wed, 8 Feb 2017 18:04:47 +0000

Eric,
I was never quite happy with the outcome that neither 0 nor 1 is a valid SI.
(Because if received with value of 1, it is decremented and discarded.)

It seems to waste an index value.

I guess I'm interested to know if that is important to other implementers, or if that was even the intention?

-Dave

From: sfc [mailto:[email-masked]] On Behalf Of Eric C Rosen
Sent: Wednesday, February 08, 2017 11:53 AM
To: James N Guichard; [email-masked]
Subject: Re: [sfc] NSH Service Index Decrement

- The term "SFC Proxy node" is not defined in either the NSH draft or in RFC 7665.  I think the intention here is to say "SFC Proxy".

- Is the intention that the SI remain unchanged while the SF is operating on the packet, or is the intention only that the SI be decremented before the packet is delivered by the SF or SFC Proxy to an SFF?

I'd suggest either:

"An SF or SFC Proxy receiving an NSH-encapsulated packet MUST decrement the SI by 1 before delivering the packet to the next SFF"

or

"An SF or SFC Proxy receiving an NSH-encapsulated packet MUST decrement the SI by 1 before delivering the packet to the next SFF, but not until the SF has finished all its other processing of the packet"

I think an implication of these procedures is that an SI value of 1 is not valid.  If an SF gets an NSH packet with an SI of 1, the SF will decrement the SI (setting it to 0), send the packet to an SFF, and the SFF will discard it, because 0 is an invalid SI value.  Is that the intention?

The draft makes it clear (well, sort of) that an SFF should discard a packet with an SI of 0, but does not seem to say that an SF or SFC Proxy should discard a packet it receives with an SI of 0.  It would probably be a good idea to say that.

Some text in the draft (e.g., section 7.1) states than an SFF should discard a packet with an SI of zero, but other text in the draft (e.g., section 3.3) only says that an SFF should log an error if it sees an SI of zero.  It's probably best to change the text in 3.3. to say "SHOULD generate an error/log message and MUST discard the packet", or something similar.

---

From: "Dolganow, Andrew (Nokia - SG)" <[email-masked]>
Date: Thu, 9 Feb 2017 01:50:42 +0000

I assumed that if we get value 1 we process then forward without NSH header (i.e.) this is the last SF processing.

So with that assumption, a more explicit text would be:

An SF or SFC Proxy receiving an NSH-encapsulated packet MUST decrement the SI by 1 after performing all required local processing and before forwarding the packet to the next SFF. If the resulting SI is 0, the SF MUST remove the NSH header before forwarding the packet.

Andrew
From: sfc <[email-masked]> on behalf of Dave Dolson <[email-masked]>
Date: Thursday, February 9, 2017 at 2:04 AM
To: Eric Rosen <[email-masked]>, James N Guichard <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [sfc] NSH Service Index Decrement

Eric,

I guess I’m interested to know if that is important to other implementers, or if that was even the intention?

-Dave

I'd suggest either:

or

---

From: Fabricio Ferraz <[email-masked]>
Date: Thu, 9 Feb 2017 12:12:34 +0000

Hi all,
I’m new here (just read the draft last week) but according to chapter 4 (check figure 8 for example), an SF is not allowed to insert or remove NSH. The removal of NSH is reponsability of the SSF, right?

  Figure 8 maps each of the four actions above to the components in the
   SFC architecture that can perform it.

+---------------+------------------+-------+----------------+---------+
|                |  Insert         |Select |   Update       |Service  |
|                |  or remove NSH  |Service|    NSH         |policy   |
|                |                 |Function|               |selection|
| Component      +--------+--------+Path   +----------------+         |
|                |        |        |       | Dec.   |Update |         |
|                | Insert | Remove |       |Service |Context|         |
|                |        |        |       | Index  |Header |         |
+----------------+--------+--------+-------+--------+-------+---------+
|                |   +    |   +    |       |        |   +   |         |
|Classifier      |        |        |       |        |       |         |
+--------------- +--------+--------+-------+--------+-------+---------+
|Service Function|        |   +    |  +    |        |       |         |
|Forwarder(SFF)  |        |        |       |        |       |         |
+--------------- +--------+--------+-------+--------+-------+---------+
|Service         |        |        |       |   +    |   +   |   +     |
|Function  (SF)  |        |        |       |        |       |         |
+--------------- +--------+--------+-------+--------+-------+---------+
|SFC Proxy       |   +    |   +    |       |   +    |       |         |
+----------------+--------+--------+-------+--------+-------+---------+

                   Figure 8: NSH Action and Role Mapping

An SF could receive an NSH packet with an SI of 1, and reclassify it to a different SPI and SI, right? So when a SF receives a NSH packet with SI = 1 that does not necessarily means a non valid packet.
And that can even work for SI=0, since you decrement the SI in the egress.

Fabricio

From: sfc [mailto:[email-masked]] On Behalf Of Dolganow, Andrew (Nokia - SG)
Sent: quinta-feira, 9 de fevereiro de 2017 01:51
To: Dave Dolson; Eric C Rosen; James N Guichard; [email-masked]
Subject: Re: [sfc] NSH Service Index Decrement

Andrew
From: sfc <[email-masked]<mailto:[email-masked]>> on behalf of Dave Dolson <[email-masked]<mailto:[email-masked]>>
Date: Thursday, February 9, 2017 at 2:04 AM
To: Eric Rosen <[email-masked]<mailto:[email-masked]>>, James N Guichard <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] NSH Service Index Decrement

Eric,

-Dave

From: sfc [mailto:[email-masked]] On Behalf Of Eric C Rosen
Sent: Wednesday, February 08, 2017 11:53 AM
To: James N Guichard; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] NSH Service Index Decrement

I'd suggest either:

or

---

From: James N Guichard <[email-masked]>
Date: Thu, 9 Feb 2017 16:22:10 +0000

Hi Andrew,

The last sentence is incorrect as the current architecture specifies that removal of NSH is the responsibility of an SFF and/or re-classifier (see section 4, bullet point 1 for the relevant text).

The SF responsibility is simply to decrement the SI by a value of 1.

Jim

From: Dolganow, Andrew (Nokia - SG) [mailto:[email-masked]]
Sent: Wednesday, February 08, 2017 8:51 PM
To: Dave Dolson <[email-masked]>; Eric C Rosen <[email-masked]>; James N Guichard <[email-masked]>; [email-masked]
Subject: Re: [sfc] NSH Service Index Decrement

Andrew

Eric,

-Dave

I'd suggest either:

or

---

From: James N Guichard <[email-masked]>
Date: Thu, 9 Feb 2017 16:25:25 +0000

Hi Fabricio,

Welcome!

Yes, removal of NSH is the responsibility of an SFF or a re-classifier (section 4, bullet point 1 lays this out). With the current architecture the SF does not care what SI value it gets, it just needs to worry about decrementing it, and leave it up to the SFF to evaluate the SI value and associated action.

Jim

From: Fabricio Ferraz [mailto:[email-masked]]
Sent: Thursday, February 09, 2017 7:13 AM
To: Dolganow, Andrew (Nokia - SG) <[email-masked]>; Dave Dolson <[email-masked]>; Eric C Rosen <[email-masked]>; James N Guichard <[email-masked]>; [email-masked]
Subject: RE: [sfc] NSH Service Index Decrement

Hi all,

Fabricio

From: sfc [mailto:[email-masked]] On Behalf Of Dolganow, Andrew (Nokia - SG)
Sent: quinta-feira, 9 de fevereiro de 2017 01:51
To: Dave Dolson; Eric C Rosen; James N Guichard; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] NSH Service Index Decrement

Andrew

Eric,

-Dave

I'd suggest either:

or

---

From: Fabricio Ferraz <[email-masked]>
Date: Thu, 9 Feb 2017 16:48:40 +0000

Hi Jim,
Thanks.

One more question about the SI.

Section 3 states that:

Service Index (SI): provides location within the SFP. The initial classifier MUST set the appropriate SI value for a given classification result. The initial SI value SHOULD default to 255. However, the classifier MUST allow configuration of other SI values.
Service Index MUST be decremented by Service Functions or by SFC Proxy nodes after performing required services and the new decremented SI value MUST be used in the egress NSH packet.
The initial Classifier MUST send the packet to the first SFF in the identified SFP for forwarding along an SFP.
If re-classification occurs, and that re-classification results in a new SPI, the (re)classifier is, in effect, the initial classifier for the resultant SPI.

Thus:

a)      Initial SI value should be 255 but other values can be configured by the classifier.

b)      SF decrements the SI value on the egress NSH packet

c)       If re-classification occurs with new SPI, the re-classifier is the initial classifier, so by  a), SI should be again 255 or other value

So any SI value can be receive by an SF, even 1 or 0 because:

è If SI=1 and there is no re-classification, the egress NSH will have SI=0

è If SI=0 and there is re-classification with new SPI, the egress NSH will have a new SPI and a SI= 255 or other value, as stated in a).

è If SI=0 and there is no re-classification the SF should discard the packet

Also an SFF should forward/handle packets with NSH with SI=1 or SI=0.

Do you agree?

From: sfc [mailto:[email-masked]] On Behalf Of James N Guichard
Sent: quinta-feira, 9 de fevereiro de 2017 16:25
To: Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave Dolson; Eric C Rosen; [email-masked]
Subject: Re: [sfc] NSH Service Index Decrement

Hi Fabricio,

Welcome!

Jim

From: Fabricio Ferraz [mailto:[email-masked]]
Sent: Thursday, February 09, 2017 7:13 AM
To: Dolganow, Andrew (Nokia - SG) <[email-masked]<mailto:[email-masked]>>; Dave Dolson <[email-masked]<mailto:[email-masked]>>; Eric C Rosen <[email-masked]<mailto:[email-masked]>>; James N Guichard <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [sfc] NSH Service Index Decrement

Hi all,

Fabricio

Andrew

Eric,

-Dave

I'd suggest either:

or

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 9 Feb 2017 12:00:17 -0500

An SF should never receive a packet with SI 0.  But it is not its 
responsibility to enforce that.

An SFF that receives a packet with SI 0 is required to drop that packet.
Usually, an SFF which is expected to receive an SI of 1 for a given SPI 
is also configured to be the termination / egress for that SPI.  It is 
legal for the index 1 to go to an SF and a reclassifier, and thus get 
NEW NSH information.  This would correspond to a case where there are 
multiple alternative next service function paths, none of them being 
continuations of the original path.

I am not sure what the "Egress NSH" is in your description.
Remember that a classifier or reclassifier is (archtiecturally) separate 
from an SF or an SFF.  It is a distinct set of fnctionality.

Yours,
Joel

On 2/9/17 11:48 AM, Fabricio Ferraz wrote:
> Service Index (SI): provides location within the SFP. The initial
> classifier MUST set the appropriate SI value for a given classification
> result. The initial SI value SHOULD default to 255. However, the
> classifier MUST allow configuration of other SI values.
>
> Service Index MUST be decremented by Service Functions or by SFC Proxy
> nodes after performing required services and the new decremented SI
> value MUST be used in the egress NSH packet.
>
> The initial Classifier MUST send the packet to the first SFF in the
> identified SFP for forwarding along an SFP.
>
> If re-classification occurs, and that re-classification results in a new
> SPI, the (re)classifier is, in effect, the initial classifier for the
> resultant SPI.
>
>
>
> Thus:
>
> c)       If re-classification occurs with new SPI, the re-classifier is
> the initial classifier, so by  a), SI should be again 255 or other value
>
>
>
> èIf SI=1 and there is no re-classification, the egress NSH will have SI=0
>
> èIf SI=0 and there is re-classification with new SPI, the egress NSH
> will have a new SPI and a SI= 255 or other value, as stated in a).
>
> èIf SI=0 and there is no re-classification the SF should discard the packet
>
>
>
> *From:*sfc [mailto:[email-masked]] *On Behalf Of *James N Guichard
> *Sent:* quinta-feira, 9 de fevereiro de 2017 16:25
> *To:* Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave Dolson; Eric
> C Rosen; [email-masked]
> *Subject:* Re: [sfc] NSH Service Index Decrement
>
>
>
> Hi Fabricio,
>
>
>
> Welcome!
>
>
>
> Yes, removal of NSH is the responsibility of an SFF or a re-classifier
> (section 4, bullet point 1 lays this out). With the current architecture
> the SF does not care what SI value it gets, it just needs to worry about
> decrementing it, and leave it up to the SFF to evaluate the SI value and
> associated action.
>
>
>
> Jim
>
>
>
> *From:*Fabricio Ferraz [mailto:[email-masked]]
> *Sent:* Thursday, February 09, 2017 7:13 AM
> *To:* Dolganow, Andrew (Nokia - SG) <[email-masked]
> <mailto:[email-masked]>>; Dave Dolson <[email-masked]
> <mailto:[email-masked]>>; Eric C Rosen <[email-masked]
> <mailto:[email-masked]>>; James N Guichard
> <[email-masked] <mailto:[email-masked]>>;
> [email-masked] <mailto:[email-masked]>
> *Subject:* RE: [sfc] NSH Service Index Decrement
>
>
>
> Hi all,
>
> I’m new here (just read the draft last week) but according to chapter 4
> (check figure 8 for example), an SF is not allowed to insert or remove
> NSH. The removal of NSH is reponsability of the SSF, right?
>
>
>
> An SF could receive an NSH packet with an SI of 1, and reclassify it to
> a different SPI and SI, right? So when a SF receives a NSH packet with
> SI = 1 that does not necessarily means a non valid packet.
>
> *From:*sfc [mailto:[email-masked]] *On Behalf Of *Dolganow, Andrew
> (Nokia - SG)
> *Sent:* quinta-feira, 9 de fevereiro de 2017 01:51
> *To:* Dave Dolson; Eric C Rosen; James N Guichard; [email-masked]
> <mailto:[email-masked]>
> *Subject:* Re: [sfc] NSH Service Index Decrement
>
>
>
> I assumed that if we get value 1 we process then forward without NSH
> header (i.e.) this is the last SF processing.
>
>
>
> An SF or SFC Proxy receiving an NSH-encapsulated packet MUST decrement
> the SI by 1 after performing all required local processing and before
> forwarding the packet to the next SFF. If the resulting SI is 0, the SF
> MUST remove the NSH header before forwarding the packet.
>
>
>
> Andrew
>
> *From: *sfc <[email-masked] <mailto:[email-masked]>> on
> behalf of Dave Dolson <[email-masked] <mailto:[email-masked]>>
> *Date: *Thursday, February 9, 2017 at 2:04 AM
> *To: *Eric Rosen <[email-masked] <mailto:[email-masked]>>, James
> N Guichard <[email-masked]
> <mailto:[email-masked]>>, "[email-masked]
> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> *Subject: *Re: [sfc] NSH Service Index Decrement
>
>
>
> Eric,
>
> I guess I’m interested to know if that is important to other
> implementers, or if that was even the intention?
>
>
>
>
>
> -Dave
>
>
>
>
>
>
>
> *From:*sfc [mailto:[email-masked]] *On Behalf Of *Eric C Rosen
> *Sent:* Wednesday, February 08, 2017 11:53 AM
> *To:* James N Guichard; [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [sfc] NSH Service Index Decrement
>
>
>
> [email-masked]

---

From: James N Guichard <[email-masked]>
Date: Thu, 9 Feb 2017 17:02:21 +0000

Not exactly. Section 3.3 specifies “The value zero for SI is not valid and indicates a broken SFC or malfunctioning SF” .. In other words an SF should never receive an NSH packet with SI = 0. Note that if this happened then either a) a classifier set the SI incorrectly, or b) a re-classifier set the SI incorrectly, or c) an upstream SF set the SI incorrectly; all of these cases should be caught by the SFF whose job it is to discard NSH packets with SI = 0.

Jim

From: Fabricio Ferraz [mailto:[email-masked]]
Sent: Thursday, February 09, 2017 11:49 AM
To: James N Guichard <[email-masked]>; Dolganow, Andrew (Nokia - SG) <[email-masked]>; Dave Dolson <[email-masked]>; Eric C Rosen <[email-masked]>; [email-masked]
Subject: RE: [sfc] NSH Service Index Decrement

Hi Jim,
Thanks.

Section 3 states that:

Thus:

Do you agree?

From: sfc [mailto:[email-masked]] On Behalf Of James N Guichard
Sent: quinta-feira, 9 de fevereiro de 2017 16:25
To: Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave Dolson; Eric C Rosen; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] NSH Service Index Decrement

Hi Fabricio,

Welcome!

Jim

Hi all,

Fabricio

Andrew

Eric,

-Dave

I'd suggest either:

or

---

From: Dave Dolson <[email-masked]>
Date: Thu, 9 Feb 2017 17:28:19 +0000

I’m not clear on why this is broken, or why this restriction is made.
I agree it should not be sent to an SF, but an SFF could map an SI of zero into a path termination.
I.e., the last SF in a path could decrement SI from 1 to 0, and the SFF could then terminate the chain.

From: sfc [mailto:[email-masked]] On Behalf Of James N Guichard
Sent: Thursday, February 09, 2017 12:02 PM
To: Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave Dolson; Eric C Rosen; [email-masked]
Subject: Re: [sfc] NSH Service Index Decrement

Jim

Hi Jim,
Thanks.

Section 3 states that:

Thus:

Do you agree?

Hi Fabricio,

Welcome!

Jim

Hi all,

Fabricio

Andrew

Eric,

-Dave

I'd suggest either:

or

---

From: Ron Parker <[email-masked]>
Date: Thu, 9 Feb 2017 17:42:34 +0000

agree.

On Feb 9, 2017, at 12:28 PM, Dave Dolson <[email-masked]<mailto:[email-masked]>> wrote:

Jim

From: Fabricio Ferraz [mailto:[email-masked]]
Sent: Thursday, February 09, 2017 11:49 AM
To: James N Guichard <[email-masked]<mailto:[email-masked]>>; Dolganow, Andrew (Nokia - SG) <[email-masked]<mailto:[email-masked]>>; Dave Dolson <[email-masked]<mailto:[email-masked]>>; Eric C Rosen <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [sfc] NSH Service Index Decrement

Hi Jim,
Thanks.

Section 3 states that:

Thus:

Do you agree?

Hi Fabricio,

Welcome!

Jim

Hi all,

Fabricio

Andrew

Eric,

-Dave

I'd suggest either:

or

---

From: James N Guichard <[email-masked]>
Date: Thu, 9 Feb 2017 17:57:54 +0000

This mechanism has been in the document for the past x years and is not dissimilar to what a router will do with a packet whose TTL = 0 e.g. something broke, drop the packet and tell someone you did that.

Jim

From: Ron Parker [mailto:[email-masked]]
Sent: Thursday, February 09, 2017 12:43 PM
To: Dave Dolson <[email-masked]>
Cc: James N Guichard <[email-masked]>; Fabricio Ferraz <[email-masked]>; Dolganow, Andrew (Nokia - SG) <[email-masked]>; Eric C Rosen <[email-masked]>; [email-masked]
Subject: Re: [sfc] NSH Service Index Decrement

agree.

On Feb 9, 2017, at 12:28 PM, Dave Dolson <[email-masked]<mailto:[email-masked]>> wrote:
I'm not clear on why this is broken, or why this restriction is made.
I agree it should not be sent to an SF, but an SFF could map an SI of zero into a path termination.
I.e., the last SF in a path could decrement SI from 1 to 0, and the SFF could then terminate the chain.

Not exactly. Section 3.3 specifies "The value zero for SI is not valid and indicates a broken SFC or malfunctioning SF" .. In other words an SF should never receive an NSH packet with SI = 0. Note that if this happened then either a) a classifier set the SI incorrectly, or b) a re-classifier set the SI incorrectly, or c) an upstream SF set the SI incorrectly; all of these cases should be caught by the SFF whose job it is to discard NSH packets with SI = 0.

Jim

Hi Jim,
Thanks.

Section 3 states that:

Thus:

? If SI=1 and there is no re-classification, the egress NSH will have SI=0

? If SI=0 and there is re-classification with new SPI, the egress NSH will have a new SPI and a SI= 255 or other value, as stated in a).

? If SI=0 and there is no re-classification the SF should discard the packet

Do you agree?

Hi Fabricio,

Welcome!

Jim

Hi all,
I'm new here (just read the draft last week) but according to chapter 4 (check figure 8 for example), an SF is not allowed to insert or remove NSH. The removal of NSH is reponsability of the SSF, right?

Fabricio

Andrew

Eric,

-Dave

I'd suggest either:

or

---

From: "Fedyk, Don" <[email-masked]>
Date: Thu, 9 Feb 2017 19:34:10 +0000

I think now that there is a distinct TTL the SI text can be relaxed a bit.  The SI was serving multi purposes previously.  Chains should be able to operate normally on any value returned from an SF including 0.  At the SFF the lookup of SID/SI has to be valid.

Cheers
Don

From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: Thursday, February 09, 2017 12:28 PM
To: James N Guichard <[email-masked]>; Fabricio Ferraz <[email-masked]>; Dolganow, Andrew (Nokia - SG) <[email-masked]>; Eric C Rosen <[email-masked]>; [email-masked]
Subject: Re: [sfc] NSH Service Index Decrement

Jim

Hi Jim,
Thanks.

Section 3 states that:

Thus:

Do you agree?

Hi Fabricio,

Welcome!

Jim

Hi all,

Fabricio

Andrew

Eric,

-Dave

I'd suggest either:

or

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 9 Feb 2017 14:53:44 -0500

From my perspective as an individual participant in this work, 
declaring that 0 must be dropped is a matter of robustness.

if we allow 0 to be processed for exit at an SFF, then a mis-configured 
SFF could easily continue processing such a packet.  Now, it is true 
that TTL will eventually drop it, but that is an expensive fallback.

More importantly, presumably the next entitiy down the incorrect path 
would drop it for a 255 SI.  But at that point we are getting the error 
in the wrong place, making it harder to diagnose and repair.

Yours,
Joel

On 2/9/17 12:42 PM, Ron Parker wrote:
>> *Sent:* Thursday, February 09, 2017 12:02 PM
>> *To:* Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave Dolson;
>> Eric C Rosen; [email-masked] <mailto:[email-masked]>
>> Not exactly. Section 3.3 specifies “The value zero for SI is not valid
>> and indicates a broken SFC or malfunctioning SF” .. In other words an
>> SF should never receive an NSH packet with SI = 0. Note that if this
>> happened then either a) a classifier set the SI incorrectly, or b) a
>> re-classifier set the SI incorrectly, or c) an upstream SF set the SI
>> incorrectly; all of these cases should be caught by the SFF whose job
>> it is to discard NSH packets with SI = 0.
>>
>>
>>
>> Jim
>>
>>
>>
>> *Sent:* Thursday, February 09, 2017 11:49 AM
>> *To:* James N Guichard <[email-masked]
>> <mailto:[email-masked]>>; Dolganow, Andrew (Nokia - SG)
>> <[email-masked] <mailto:[email-masked]>>; Dave
>> Dolson <[email-masked] <mailto:[email-masked]>>; Eric C
>> Rosen <[email-masked] <mailto:[email-masked]>>; [email-masked]
>> <mailto:[email-masked]>
>> classifier MUST set the appropriate SI value for a given
>> classification result. The initial SI value SHOULD default to 255.
>> However, the classifier MUST allow configuration of other SI values.
>>
>> If re-classification occurs, and that re-classification results in a
>> new SPI, the (re)classifier is, in effect, the initial classifier for
>> the resultant SPI.
>>
>>
>>
>> Thus:
>>
>> c)       If re-classification occurs with new SPI, the re-classifier
>> is the initial classifier, so by  a), SI should be again 255 or other
>> value
>>
>>
>>
>> *To:* Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave Dolson;
>> Eric C Rosen; [email-masked] <mailto:[email-masked]>
>> (section 4, bullet point 1 lays this out). With the current
>> architecture the SF does not care what SI value it gets, it just needs
>> to worry about decrementing it, and leave it up to the SFF to evaluate
>> the SI value and associated action.
>>
>>
>>
>> Jim
>>
>>
>>
>> I’m new here (just read the draft last week) but according to chapter
>> 4 (check figure 8 for example), an SF is not allowed to insert or
>> remove NSH. The removal of NSH is reponsability of the SSF, right?
>>
>>
>>
>> An SF could receive an NSH packet with an SI of 1, and reclassify it
>> to a different SPI and SI, right? So when a SF receives a NSH packet
>> with SI = 1 that does not necessarily means a non valid packet.
>>
>> *From:*sfc [mailto:[email-masked]] *On Behalf Of *Dolganow,
>> Andrew (Nokia - SG)
>> forwarding the packet to the next SFF. If the resulting SI is 0, the
>> SF MUST remove the NSH header before forwarding the packet.
>>
>>
>>
>> Andrew
>>
>> *To: *Eric Rosen <[email-masked] <mailto:[email-masked]>>,
>> James N Guichard <[email-masked]
>> - The term "SFC Proxy node" is not defined in either the NSH draft or
>> in RFC 7665.  I think the intention here is to say "SFC Proxy".
>>
>> decremented before the packet is delivered by the SF or SFC Proxy to
>> an SFF?
>>
>> I'd suggest either:
>>
>> "An SF or SFC Proxy receiving an NSH-encapsulated packet MUST
>> decrement the SI by 1 before delivering the packet to the next SFF"
>>
>> or
>>
>> "An SF or SFC Proxy receiving an NSH-encapsulated packet MUST
>> decrement the SI by 1 before delivering the packet to the next SFF,
>> but not until the SF has finished all its other processing of the packet"
>>
>> packet with an SI of 0, but does not seem to say that an SF or SFC
>> Proxy should discard a packet it receives with an SI of 0.  It would
>> probably be a good idea to say that.
>>
>> discard a packet with an SI of zero, but other text in the draft
>> (e.g., section 3.3) only says that an SFF should log an error if it
>> sees an SI of zero.  It's probably best to change the text in 3.3. to
>> say "SHOULD generate an error/log message and MUST discard the
>> packet", or something similar.
>>

---

From: "Fedyk, Don" <[email-masked]>
Date: Thu, 9 Feb 2017 20:38:41 +0000

Hi Joel

I think the question is can an SF return an SI = 0 and then the SFF look up an SID/SI=0 and do something useful?
Certainly after SI = 0 now at an SFF, forwarding on the packet to another SF with SI= 0 is not useful but is protected at the SF. (also there is no rolling over to 255 at an SF). 
Somehow I think we got caught up on a corner case.  I'd expect very few chains ever to be hitting SI = 0 if they start at SI = 255.  But the question remains is SI = 0 a legal return value? 

Cheers
Don 

> -----Original Message-----
> From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
> Sent: Thursday, February 09, 2017 2:54 PM
> To: Ron Parker <[email-masked]>; Dave Dolson
> <[email-masked]>
> Cc: Fabricio Ferraz <[email-masked]>; James N Guichard
> <[email-masked]>; [email-masked]; Eric C Rosen
> <[email-masked]>; Dolganow, Andrew (Nokia - SG)
> <[email-masked]>
>  From my perspective as an individual participant in this work, declaring that 0
> must be dropped is a matter of robustness.
> 
> if we allow 0 to be processed for exit at an SFF, then a mis-configured SFF could
> easily continue processing such a packet.  Now, it is true that TTL will
> eventually drop it, but that is an expensive fallback.
> 
> More importantly, presumably the next entitiy down the incorrect path would
> drop it for a 255 SI.  But at that point we are getting the error in the wrong
> place, making it harder to diagnose and repair.
> 
> Yours,
> Joel
> 
> >> Not exactly. Section 3.3 specifies "The value zero for SI is not
> >> valid and indicates a broken SFC or malfunctioning SF" .. In other
> >> words an SF should never receive an NSH packet with SI = 0. Note that
> >> if this happened then either a) a classifier set the SI incorrectly,
> >> or b) a re-classifier set the SI incorrectly, or c) an upstream SF
> >> set the SI incorrectly; all of these cases should be caught by the
> >> SFF whose job it is to discard NSH packets with SI = 0.
> >>
> >>
> >>
> >> Jim
> >>
> >>
> >>
> >> Service Index MUST be decremented by Service Functions or by SFC
> >> Proxy nodes after performing required services and the new
> >> decremented SI value MUST be used in the egress NSH packet.
> >>
> >> Yes, removal of NSH is the responsibility of an SFF or a
> >> re-classifier (section 4, bullet point 1 lays this out). With the
> >> current architecture the SF does not care what SI value it gets, it
> >> just needs to worry about decrementing it, and leave it up to the SFF
> >> to evaluate the SI value and associated action.
> >>
> >>
> >>
> >> Jim
> >>
> >>
> >>
> >> <mailto:[email-masked]>>; Dave Dolson
> >> <[email-masked] <mailto:[email-masked]>>; Eric C Rosen
> >> <[email-masked] <mailto:[email-masked]>>; James N Guichard
> >> I'm new here (just read the draft last week) but according to chapter
> >> +---------------
> >> ++--------+--------+-------+--------+-------+---------+
> >>
> >> +---------------
> >> ++--------+--------+-------+--------+-------+---------+
> >>
> >> +---------------
> >> ++--------+--------+-------+--------+-------+---------+
> >>
> >> An SF or SFC Proxy receiving an NSH-encapsulated packet MUST
> >> decrement the SI by 1 after performing all required local processing
> >> and before forwarding the packet to the next SFF. If the resulting SI
> >> is 0, the SF MUST remove the NSH header before forwarding the packet.
> >>
> >>
> >>
> >> Andrew
> >>
> >> I guess I'm interested to know if that is important to other
> >> "Service index MUST be decremented *by a value of 1* by Service
> >> Functions or by SFC Proxy nodes after performing required services ."
> >>
> >>
> >> I think an implication of these procedures is that an SI value of 1
> >> is not valid.  If an SF gets an NSH packet with an SI of 1, the SF
> >> will decrement the SI (setting it to 0), send the packet to an SFF,
> >> and the SFF will discard it, because 0 is an invalid SI value.  Is
> >> that the intention?
> >>

---

From: Dave Dolson <[email-masked]>
Date: Thu, 9 Feb 2017 21:00:22 +0000

Discussing misconfigured SFFs is a straw-man argument. Once one starts trying to anticipate down-stream devices being misconfigured, one can invent a lot of silly requirements.

>From an aesthetic point of view, I think it's bad that there are two SI values (0 and 1) that cannot be used.

The real requirement, IMO, is that no device decrements 0 and forwards NSH.
Since only SFs decrement SI, only SFs need to do this check.

And any discussion about buggy SFs... well there is a lot of bad stuff that bugs can cause.

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Thursday, February 09, 2017 2:54 PM
To: Ron Parker; Dave Dolson
Cc: Eric C Rosen; [email-masked]; Dolganow, Andrew (Nokia - SG); James N Guichard; Fabricio Ferraz
Subject: Re: [sfc] NSH Service Index Decrement

Yours,
Joel

On 2/9/17 12:42 PM, Ron Parker wrote:
>> Not exactly. Section 3.3 specifies "The value zero for SI is not valid
>> and indicates a broken SFC or malfunctioning SF" .. In other words an

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 10 Feb 2017 14:16:10 -0000

Oh, you finally pushed me into this discussion, Dave.

We're building a protocol. with a protocol, you cannot (must not) assume good
behavior from your neighbor.

So if the SF touches the SI (which it does) we must define the edge conditions. 
If it is the SF's job to decrement the SI, then we must also define what it does
when SI=0 (otherwise, it will set SI to 0-1).
If the SF is not allowed to decrement the SI below zero (which makes sense) we
must define what it must do.
Since SFs are allowed to drop packets (indeed that is one of their main jobs ;-)
then this would be fine.
All that would be left is to define whether they apply the test before or after
normal processing.

As an aside, I agree with Don that TTL helps relax this a little, but does not
get us all the way there.

Cheers,
Adrian

> Sent: 09 February 2017 21:00
> To: Joel M. Halpern; Ron Parker
> Cc: Fabricio Ferraz; James N Guichard; [email-masked]; Eric C Rosen; Dolganow,
> Andrew (Nokia - SG)
> Discussing misconfigured SFFs is a straw-man argument. Once one starts trying
to
> anticipate down-stream devices being misconfigured, one can invent a lot of
silly
> requirements.
> 
> >From an aesthetic point of view, I think it's bad that there are two SI
values (0
> and 1) that cannot be used.
> 
> And any discussion about buggy SFs... well there is a lot of bad stuff that
bugs can
> cause.
> Cc: Eric C Rosen; [email-masked]; Dolganow, Andrew (Nokia - SG); James N
Guichard;
> Fabricio Ferraz
> <[email-masked]

---

From: Dave Dolson <[email-masked]>
Date: Fri, 10 Feb 2017 22:26:04 +0000

Adrian,
I think I agree with everything you said.
But you did not suggest whether or not you think that SI=0 should be valid on the wire.
I'm saying it could work, if the next hop is a path terminus.

If I understand Joel correctly, he says we shouldn't send SI=0  in case the next hop blindly decrements it.
--> this seems to mean SI=1 cannot be used except at the terminus or when the SF is expected to drop all packets.
So I think this is an unnecessary seat belt, trying to anticipate bugs in down-stream devices.

I realize the current language has been there a long time, and if it is important to anyone then it should remain.
Nonetheless, I think devices could safely handle SI=0 on the wire without breaking anything.

But I'm not pushing for a change, since the current behavior seems important to some.

-Dave

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Friday, February 10, 2017 9:16 AM
To: Dave Dolson; 'Joel M. Halpern'; 'Ron Parker'
Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; [email-masked]; 'James N Guichard'; 'Fabricio Ferraz'
Subject: Re: [sfc] NSH Service Index Decrement

Cheers,
Adrian

to
silly
values (0
bugs can
Guichard;

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 11 Feb 2017 16:34:13 -0000

I hate to do my impersonation of Eric, but...

"On the wire" is the crunch.

Some have said that there must be no visible difference between the three case:
- on the wire between SFF and SF
- on the wire between SF and SFF
- on the wire between SFF and SFF

If this holds then you are correct that sending SI=1 in the first case requires
the SF to do more than a simple decrement (although decrement and discard is
hardly painful). And it means that SI=1 is a dubious value in an SFP.

On the other hand, we appear to be clear about an SF that strips the NSH and
forwards the traffic as native : this is currently forbidden. So there is no
alternative for an SF receiving SI=1 except to discard the packet.

Now, does that mean that an SFF should never send a packet with SI=1? Well,
possibly it is OK for a few specialist SFs intended to sit at the end of the
chain and be a bit bucket with analysis. But, for most SFs there would be no
point.

Maybe (just maybe) we should stop letting the tail wag the dog! That is, let's
decide on the functional behavior we want to see and then design the protocol to
match.

Adrian

> From: Dave Dolson [mailto:[email-masked]]
> Sent: 10 February 2017 22:26
> To: [email-masked]; 'Joel M. Halpern'; 'Ron Parker'
> But you did not suggest whether or not you think that SI=0 should be valid on
the
> wire.
> If I understand Joel correctly, he says we shouldn't send SI=0  in case the
next
> hop blindly decrements it.
> So I think this is an unnecessary seat belt, trying to anticipate bugs in
down-
> stream devices.
> 
> I realize the current language has been there a long time, and if it is
important to
> anyone then it should remain.
> But I'm not pushing for a change, since the current behavior seems important
to
> some.

---

From: Ron Parker <[email-masked]>
Date: Sat, 11 Feb 2017 16:55:06 +0000

Hi, Adrian.

Not the original topic, per se, but wrt your comment:

* On the other hand, we appear to be clear about an SF that strips the NSH and forwards the traffic as native : this is currently forbidden.

I'm wondering how to reconcile this to a transparent HTTP Proxy that does not preserve the original source-IP?   Does this mean that it is mandatory for such an SF to also be a classifier so it can self-classify its own related flows (i.e., using its own visible IP addresses)?    From SFF perspective, it would look like all packets on the access side are dropped in the upstream direction and injected by the SF in the downstream direction.   On the Internet side, it would look like all packets are injected by the SF in the upstream direction and dropped in the downstream direction.

Thanks for any clarification.

   Ron

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Saturday, February 11, 2017 11:34 AM
To: 'Dave Dolson' <[email-masked]>; 'Joel M. Halpern' <[email-masked]>; Ron Parker <[email-masked]>
Cc: 'Eric C Rosen' <[email-masked]>; 'Dolganow, Andrew (Nokia - SG)' <[email-masked]>; [email-masked]; 'James N Guichard' <[email-masked]>; 'Fabricio Ferraz' <[email-masked]>
Subject: RE: [sfc] NSH Service Index Decrement

If this holds then you are correct that sending SI=1 in the first case requires the SF to do more than a simple decrement (although decrement and discard is hardly painful). And it means that SI=1 is a dubious value in an SFP.

On the other hand, we appear to be clear about an SF that strips the NSH and forwards the traffic as native : this is currently forbidden. So there is no alternative for an SF receiving SI=1 except to discard the packet.

Now, does that mean that an SFF should never send a packet with SI=1? Well, possibly it is OK for a few specialist SFs intended to sit at the end of the chain and be a bit bucket with analysis. But, for most SFs there would be no point.

Maybe (just maybe) we should stop letting the tail wag the dog! That is, let's decide on the functional behavior we want to see and then design the protocol to match.

Adrian

the
next
> --> this seems to mean SI=1 cannot be used except at the terminus or 
> --> when the
> SF is expected to drop all packets.
down-
important to
to
> We're building a protocol. with a protocol, you cannot (must not) 
> assume good behavior from your neighbor.
> 
> If it is the SF's job to decrement the SI, then we must also define 
> what it
does
> If the SF is not allowed to decrement the SI below zero (which makes 
> sense) we must define what it must do.
> Since SFs are allowed to drop packets (indeed that is one of their 
> main jobs
;-)
> then this would be fine.
> All that would be left is to define whether they apply the test before 
> or
after
> normal processing.
> 
> As an aside, I agree with Don that TTL helps relax this a little, but 
> does not get us all the way there.
> 
> Cheers,
> Adrian
> 
> > Cc: Fabricio Ferraz; James N Guichard; [email-masked]; Eric C Rosen; 
> > Dolganow, Andrew (Nokia - SG)
> > Discussing misconfigured SFFs is a straw-man argument. Once one 
> > starts
trying
> > if we allow 0 to be processed for exit at an SFF, then a 
> > mis-configured SFF could easily continue processing such a packet.  
> > Now, it is true that TTL will eventually drop it, but that is an expensive fallback.
> >
> > More importantly, presumably the next entitiy down the incorrect 
> > path would drop it for a 255 SI.  But at that point we are getting 
> > the error in the wrong place, making it harder to diagnose and repair.
> >
> > Yours,
> > Joel
> >
> > >> *To:* Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave 
> > >> Dolson; Eric C Rosen; [email-masked] <mailto:[email-masked]>
> > >> valid and indicates a broken SFC or malfunctioning SF" .. In 
> > >> other words an SF should never receive an NSH packet with SI = 0. 
> > >> Note that if this happened then either a) a classifier set the SI 
> > >> incorrectly, or b) a re-classifier set the SI incorrectly, or c) 
> > >> an upstream SF set the SI incorrectly; all of these cases should 
> > >> be caught by the SFF whose job it is to discard NSH packets with SI = 0.
> > >>
> > >>
> > >>
> > >> Jim
> > >>
> > >>
> > >>
> > >> <mailto:[email-masked]>>; Dolganow, Andrew (Nokia - 
> > >> SG) <[email-masked] 
> > >> <mailto:[email-masked]>>;
> > Dave
> > >> Dolson <[email-masked] <mailto:[email-masked]>>; Eric 
> > >> C Rosen <[email-masked] <mailto:[email-masked]>>; 
> > >> The initial Classifier MUST send the packet to the first SFF in 
> > >> the identified SFP for forwarding along an SFP.
> > >>
> > >> If re-classification occurs, and that re-classification results 
> > >> in a new SPI, the (re)classifier is, in effect, the initial 
> > >> classifier for the resultant SPI.
> > >>
> > >>
> > >>
> > >> Thus:
> > >>
> > >> is the initial classifier, so by  a), SI should be again 255 or 
> > >> other value
> > >>
> > >>
> > >>
> > >> èIf SI=0 and there is re-classification with new SPI, the egress 
> > >> NSH will have a new SPI and a SI= 255 or other value, as stated in a).
> > >>
> > >> *To:* Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave 
> > >> Dolson; Eric C Rosen; [email-masked] <mailto:[email-masked]>
> > >> current architecture the SF does not care what SI value it gets, 
> > >> it just needs to worry about decrementing it, and leave it up to 
> > >> the SFF to evaluate the SI value and associated action.
> > >>
> > >>
> > >>
> > >> Jim
> > >>
> > >>
> > >>
> > >> An SF could receive an NSH packet with an SI of 1, and reclassify 
> > >> it to a different SPI and SI, right? So when a SF receives a NSH 
> > >> packet with SI = 1 that does not necessarily means a non valid packet.
> > >>
> > >> And that can even work for SI=0, since you decrement the SI in 
> > >> the
egress.
> > >> I assumed that if we get value 1 we process then forward without 
> > >> NSH header (i.e.) this is the last SF processing.
> > >>
> > >>
> > >>
> > >> decrement the SI by 1 after performing all required local 
> > >> processing and before forwarding the packet to the next SFF. If 
> > >> the resulting SI is 0, the SF MUST remove the NSH header before forwarding the packet.
> > >>
> > >>
> > >>
> > >> Andrew
> > >>
> > >> *From: *sfc <[email-masked] <mailto:[email-masked]>> 
> > >> on behalf of Dave Dolson <[email-masked]
> > <mailto:[email-masked]>>
> > >> *To: *Eric Rosen <[email-masked] 
> > >> <mailto:[email-masked]>>, James N Guichard 
> > >> <[email-masked] 
> > >> - The term "SFC Proxy node" is not defined in either the NSH 
> > >> draft or in RFC 7665.  I think the intention here is to say "SFC Proxy".
> > >>
> > >> decremented before the packet is delivered by the SF or SFC Proxy 
> > >> to an SFF?
> > >>
> > >> I'd suggest either:
> > >>
> > >> decrement the SI by 1 before delivering the packet to the next 
> > >> SFF, but not until the SF has finished all its other processing of the packet"
> > >>
> > >> I think an implication of these procedures is that an SI value of 
> > >> 1 is not valid.  If an SF gets an NSH packet with an SI of 1, the 
> > >> SF will decrement the SI (setting it to 0), send the packet to an 
> > >> SFF, and the SFF will discard it, because 0 is an invalid SI 
> > >> value.  Is that the intention?
> > >>
> > >> The draft makes it clear (well, sort of) that an SFF should 
> > >> discard a packet with an SI of 0, but does not seem to say that 
> > >> an SF or SFC Proxy should discard a packet it receives with an SI 
> > >> of 0.  It would probably be a good idea to say that.
> > >>
> > >> Some text in the draft (e.g., section 7.1) states than an SFF 
> > >> should discard a packet with an SI of zero, but other text in the 
> > >> draft (e.g., section 3.3) only says that an SFF should log an 
> > >> error if it sees an SI of zero.  It's probably best to change the 
> > >> text in 3.3. to say "SHOULD generate an error/log message and 
> > >> MUST discard the packet", or something similar.
> > >>

---

From: James N Guichard <[email-masked]>
Date: Sat, 11 Feb 2017 17:21:54 +0000

After all the back and forth of this thread I am still struggling to see what the problem is; maybe someone can clearly articulate it. The current NSH specification only talks about SI = 0 and the fact that this is invalid and an SFF should drop the packet. There is no mention of SI = 1. As far as I can tell, aside from a buggy SFF, an SF should never receive a packet with SI = 0 as the preceding SFF will have dropped the packet. Of course an SF could receive a packet with SI = 1, decrement it to 0, and then the receiving SFF would drop the packet; even in this case one could argue this is a misconfigured control plane as the receiving SFF is unable to terminate the SFP and forward the packet.

Jim

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Saturday, February 11, 2017 11:34 AM
To: 'Dave Dolson' <[email-masked]>; 'Joel M. Halpern' <[email-masked]>; 'Ron Parker' <[email-masked]>
Cc: 'Eric C Rosen' <[email-masked]>; 'Dolganow, Andrew (Nokia - SG)' <[email-masked]>; [email-masked]; James N Guichard <[email-masked]>; 'Fabricio Ferraz' <[email-masked]>
Subject: RE: [sfc] NSH Service Index Decrement

Adrian

the
next
down-
important to
to
does
;-)
after
trying
> <mailto:[email-masked]>>;
egress.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 11 Feb 2017 12:31:21 -0500

Personally, what you describe sounds like a quite reasonable case where 
a packet arrive at the SF with an SI of 1 will produce exactly the 
desired behavior.

Which suggests, to my limited view, that the current text works fine.

Yours,
Joel

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 11 Feb 2017 17:50:50 -0000

Yes, there is something "misconfigured".

If the SFF sends a packet to an SF with SI=1 we know that the packet will come
back (barring reclassification onto another SFP) with SI=0 and be discarded.

So there is very little valuable function that an SF can apply with SI=1.

It is OK if this is the case (just a waste of 1 in 255 SI values, but who can
conceive of a chain of 255 SFs?). And if it is the case then:

- Let's paint it red
- Let's clarify that it is OK for an SF to send a packet with SI=0
   (currently, IIRC, it sounds like the SF should not do that)

A

> From: James N Guichard [mailto:[email-masked]]
> Sent: 11 February 2017 17:22
> To: [email-masked]; 'Dave Dolson'; 'Joel M. Halpern'; 'Ron Parker'
> Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; [email-masked]; 'Fabricio
Ferraz'
> After all the back and forth of this thread I am still struggling to see what
the
> problem is; maybe someone can clearly articulate it. The current NSH
> specification only talks about SI = 0 and the fact that this is invalid and an
SFF
> should drop the packet. There is no mention of SI = 1. As far as I can tell,
aside
> from a buggy SFF, an SF should never receive a packet with SI = 0 as the
> preceding SFF will have dropped the packet. Of course an SF could receive a
> packet with SI = 1, decrement it to 0, and then the receiving SFF would drop
the
> packet; even in this case one could argue this is a misconfigured control
plane as
> the receiving SFF is unable to terminate the SFP and forward the packet.
> 
> Jim
> 
> To: 'Dave Dolson' <[email-masked]>; 'Joel M. Halpern'
> <[email-masked]>; 'Ron Parker' <[email-masked]>
> Cc: 'Eric C Rosen' <[email-masked]>; 'Dolganow, Andrew (Nokia - SG)'
> <[email-masked]>; [email-masked]; James N Guichard
> <[email-masked]>; 'Fabricio Ferraz' <[email-masked]>
> If this holds then you are correct that sending SI=1 in the first case
requires the SF
> to do more than a simple decrement (although decrement and discard is hardly
> painful). And it means that SI=1 is a dubious value in an SFP.
> 
chain and
> be a bit bucket with analysis. But, for most SFs there would be no point.
> 
> decide on the functional behavior we want to see and then design the protocol
> to match.
> 
> Adrian
>

---

From: Ron Parker <[email-masked]>
Date: Sat, 11 Feb 2017 17:59:49 +0000

Hi, Joel.

Does your comment pertain to my somewhat off topic question which was related to one of Adrian's tangential issues, or to Adrian's original SF=1 topic?

Thanks.

   Ron

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Saturday, February 11, 2017 12:31 PM
To: Ron Parker <[email-masked]>; [email-masked]; 'Dave Dolson' <[email-masked]>
Cc: 'Eric C Rosen' <[email-masked]>; 'Dolganow, Andrew (Nokia - SG)' <[email-masked]>; [email-masked]; 'James N Guichard' <[email-masked]>; 'Fabricio Ferraz' <[email-masked]>
Subject: Re: [sfc] NSH Service Index Decrement

Personally, what you describe sounds like a quite reasonable case where a packet arrive at the SF with an SI of 1 will produce exactly the desired behavior.

Yours,
Joel

On 2/11/17 11:55 AM, Ron Parker wrote:
> <[email-masked]>; Ron Parker <[email-masked]>
> Cc: 'Eric C Rosen' <[email-masked]>; 'Dolganow, Andrew (Nokia - 
> SG)' <[email-masked]>; [email-masked]; 'James N Guichard' 
>> All that would be left is to define whether they apply the test 
>> before or
> after
>> normal processing.
>>
>>>>> words an SF should never receive an NSH packet with SI = 0.
>>>>> If re-classification occurs, and that re-classification results in 
>>>>> a new SPI, the (re)classifier is, in effect, the initial

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 11 Feb 2017 13:07:31 -0500

I was commenting, in personal hat, about the issue of whether there was 
some sort of problem with the impact of the current description on SI=1 
packets arriving at an SF.  It seems to me that your example shows that 
such an effect is sometimes useul.
It will also sometimes produce packet drops by the SFF, when the SF does 
not terminate the packet.  Okay, so be it.
It is not even clear there is anything, in Adrian's phrase, to paint red 
here.

Yours,
Joel

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 11 Feb 2017 22:35:34 -0000

Joel,

The -10 version of NSH says

   The
   value zero for SI is not valid and indicates a broken SFC or
   malfunctioning SF.

You are saying that the latter of these is not true.
I can't tell whether the former is really true or, perhaps, represents a discard
tail of an SFC where some (but not all) packets are reclassified per Ron.

Like I said:

> Let's clarify that it is OK for an SF to send a packet with SI=0

Then (of course) it is also OK for an SFF to receive SI=0, but I think the
existing "discard" text covers that case.

Adrian

> Sent: 11 February 2017 18:08
> To: Ron Parker; [email-masked]; 'Dave Dolson'
> > Does your comment pertain to my somewhat off topic question which was
> related to one of Adrian's tangential issues, or to Adrian's original SF=1
topic?
> <[email-masked]>; [email-masked]; 'James N Guichard'
> > Personally, what you describe sounds like a quite reasonable case where a
> packet arrive at the SF with an SI of 1 will produce exactly the desired
behavior.
> >> * On the other hand, we appear to be clear about an SF that strips the NSH
> and forwards the traffic as native : this is currently forbidden.
> >>
> >> I'm wondering how to reconcile this to a transparent HTTP Proxy that does
not
> preserve the original source-IP?   Does this mean that it is mandatory for
such an
> SF to also be a classifier so it can self-classify its own related flows
(i.e., using its
> own visible IP addresses)?    From SFF perspective, it would look like all
packets
> on the access side are dropped in the upstream direction and injected by the
SF
> in the downstream direction.   On the Internet side, it would look like all
packets
> are injected by the SF in the upstream direction and dropped in the downstream
> direction.
> >>
requires
chain and
> >>>> Now, it is true that TTL will eventually drop it, but that is an
expensive
> fallback.

---

From: James N Guichard <[email-masked]>
Date: Sun, 12 Feb 2017 00:57:48 +0000

Hi Adrian,

Inline (hat off opinion) ..

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Saturday, February 11, 2017 5:36 PM
To: 'Joel M. Halpern' <[email-masked]>; 'Ron Parker' <[email-masked]>
Cc: [email-masked]
Subject: Re: [sfc] NSH Service Index Decrement

Joel,

   The

Jim> the above text is perhaps what is causing some confusion as it implies an SI of 0 from an SF is invalid. May I suggest the following text as a replacement for the above sentence:

"The value zero for SI indicates a broken SFC. Packets received at an SFF with an SI of zero MUST be discarded and the SFF SHOULD generate an error/log message". 

You are saying that the latter of these is not true.
I can't tell whether the former is really true or, perhaps, represents a discard tail of an SFC where some (but not all) packets are reclassified per Ron.

> Let's clarify that it is OK for an SF to send a packet with SI=0

Then (of course) it is also OK for an SFF to receive SI=0, but I think the existing "discard" text covers that case.

Jim> from an SF yes but not from another SFF. However, in either case, a lookup on <SPI><SI=0> should cause the SFF to discard the packet. Hopefully my above suggested text clarifies that.

Adrian

> I was commenting, in personal hat, about the issue of whether there 
> was some sort of problem with the impact of the current description on 
> SI=1 packets arriving at an SF.  It seems to me that your example 
> shows that such an effect is sometimes useul.
> It will also sometimes produce packet drops by the SFF, when the SF 
> does not terminate the packet.  Okay, so be it.
> It is not even clear there is anything, in Adrian's phrase, to paint 
> red here.
> 
> Yours,
> Joel
> 
topic?
> > To: Ron Parker <[email-masked]>; 
> > [email-masked];
> 'Dave Dolson' <[email-masked]>
behavior.
not
such an
(i.e., using its
packets
SF
packets
> are injected by the SF in the upstream direction and dropped in the 
> downstream direction.
> >>
> >> Some have said that there must be no visible difference between the 
> >> three
> case:
requires
> the SF to do more than a simple decrement (although decrement and 
> discard is hardly painful). And it means that SI=1 is a dubious value in an SFP.
> >>
> >> On the other hand, we appear to be clear about an SF that strips 
> >> the NSH
and
> forwards the traffic as native : this is currently forbidden. So there 
> is no alternative for an SF receiving SI=1 except to discard the packet.
> >>
chain and
> >> Maybe (just maybe) we should stop letting the tail wag the dog! 
> >> That is,
let's
> decide on the functional behavior we want to see and then design the 
> protocol to match.
> >>
> >> Adrian
> >>
> >>> --> this seems to mean SI=1 cannot be used except at the terminus 
> >>> --> or when the
> >>> So if the SF touches the SI (which it does) we must define the 
> >>> edge
> >> conditions.
> >>> If it is the SF's job to decrement the SI, then we must also 
> >>> define what it
> >> does
> >>> As an aside, I agree with Don that TTL helps relax this a little, 
> >>> but does not get us all the way there.
> >>>
> >>> Cheers,
> >>> Adrian
> >>>
> >>>> Cc: Fabricio Ferraz; James N Guichard; [email-masked]; Eric C 
> >>>> Rosen; Dolganow, Andrew (Nokia - SG)
> >>>> The real requirement, IMO, is that no device decrements 0 and 
> >>>> forwards
> NSH.
expensive
> >>>> path would drop it for a 255 SI.  But at that point we are 
> >>>> getting the error in the wrong place, making it harder to diagnose and repair.
> >>>>
> >>>> Yours,
> >>>> Joel
> >>>>
> >>>>>> Not exactly. Section 3.3 specifies "The value zero for SI is 
> >>>>>> not valid and indicates a broken SFC or malfunctioning SF" .. 
> >>>>>> In other words an SF should never receive an NSH packet with SI = 0.
> >>>>>> Note that if this happened then either a) a classifier set the 
> >>>>>> SI incorrectly, or b) a re-classifier set the SI incorrectly, 
> >>>>>> or c) an upstream SF set the SI incorrectly; all of these cases 
> >>>>>> should be caught by the SFF whose job it is to discard NSH 
> >>>>>> packets with SI =
0.
> >>>>>> Dolson <[email-masked] <mailto:[email-masked]>>; 
> >>>>>> Eric C Rosen <[email-masked] <mailto:[email-masked]>>; 
> >>>>>> Service Index (SI): provides location within the SFP. The 
> >>>>>> initial classifier MUST set the appropriate SI value for a 
> >>>>>> given classification result. The initial SI value SHOULD default to 255.
> >>>>>> Service Index MUST be decremented by Service Functions or by 
> >>>>>> SFC Proxy nodes after performing required services and the new 
> >>>>>> èIf SI=0 and there is re-classification with new SPI, the 
> >>>>>> egress NSH will have a new SPI and a SI= 255 or other value, as stated in a).
> >>>>>>
> >>>>>> re-classifier (section 4, bullet point 1 lays this out). With 
> >>>>>> the current architecture the SF does not care what SI value it 
> >>>>>> gets, it just needs to worry about decrementing it, and leave 
> >>>>>> it up to the SFF to evaluate the SI value and associated action.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Jim
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> <mailto:[email-masked]>>; Eric C Rosen 
> >>>>>> <[email-masked] <mailto:[email-masked]>>; James N 
> >>>>>> Guichard <[email-masked]
> >>>>>> 4 (check figure 8 for example), an SF is not allowed to insert 
> >>>>>> or remove NSH. The removal of NSH is reponsability of the SSF, right?
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> An SF could receive an NSH packet with an SI of 1, and 
> >>>>>> reclassify it to a different SPI and SI, right? So when a SF 
> >>>>>> receives a NSH packet with SI = 1 that does not necessarily means a non valid packet.
> >>>>>>
> >>>>>> *From:*sfc [mailto:[email-masked]] *On Behalf Of 
> >>>>>> *Dolganow, Andrew (Nokia - SG)
> >>>>>> I assumed that if we get value 1 we process then forward 
> >>>>>> without NSH header (i.e.) this is the last SF processing.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> *From: *sfc <[email-masked] 
> >>>>>> <mailto:[email-masked]>> on behalf of Dave Dolson 
> >>>>>> <[email-masked]
> >>>>>> draft or in RFC 7665.  I think the intention here is to say 
> >>>>>> "SFC
Proxy".
> >>>>>> operating on the packet, or is the intention only that the SI 
> >>>>>> be decremented before the packet is delivered by the SF or SFC 
> >>>>>> Proxy to an SFF?
> >>>>>>
> >>>>>> I'd suggest either:
> >>>>>>
> >>>>>> SFF, but not until the SF has finished all its other processing 
> >>>>>> of the
> packet"
> >>>>>>
> >>>>>> 1 is not valid.  If an SF gets an NSH packet with an SI of 1, 
> >>>>>> the SF will decrement the SI (setting it to 0), send the packet 
> >>>>>> to an SFF, and the SFF will discard it, because 0 is an invalid 
> >>>>>> SI value.  Is that the intention?
> >>>>>>
> >>>>>> an SF or SFC Proxy should discard a packet it receives with an 
> >>>>>> SI of 0.  It would probably be a good idea to say that.
> >>>>>>
> >>>>>> should discard a packet with an SI of zero, but other text in 
> >>>>>> the draft (e.g., section 3.3) only says that an SFF should log 
> >>>>>> an error if it sees an SI of zero.  It's probably best to 
> >>>>>> change the text in 3.3. to say "SHOULD generate an error/log 
> >>>>>> message and MUST discard the packet", or something similar.
> >>>>>>

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 12 Feb 2017 10:36:12 -0000

Thanks Jim,

Your text works for me although I would prefer to delete the commentary about a
"broken SFC" as a specific example of how this might happen that is not the only
case (for example, a broken reclassifier can also cause this).

So, can we settle on

"Packets received at an SFF with an SI of zero MUST be discarded and the SFF
SHOULD generate an error/log message."

BTW, I said
>> Then (of course) it is also OK for an SFF to receive SI=0, but I think the
existing
>> "discard" text covers that case.
and you replied
> from an SF yes but not from another SFF.
and that (of course) has been a point of entertainment for some while.
Since an SFF cannot tell the difference between a packet received from an SFF
and one from an SF we must document all cases alike.

Fortunately, we're able to do so for this instance.

A

> Sent: 12 February 2017 00:58
> Jim> the above text is perhaps what is causing some confusion as it implies an
SI
> of 0 from an SF is invalid. May I suggest the following text as a replacement
for
> the above sentence:
> 
> "The value zero for SI indicates a broken SFC. Packets received at an SFF with
an
> SI of zero MUST be discarded and the SFF SHOULD generate an error/log
> message".
> 
> I can't tell whether the former is really true or, perhaps, represents a
discard tail
> of an SFC where some (but not all) packets are reclassified per Ron.
> 
> Like I said:
> 
existing
> "discard" text covers that case.
> 
> Jim> from an SF yes but not from another SFF. However, in either case, a
lookup
> on <SPI><SI=0> should cause the SFF to discard the packet. Hopefully my above
> suggested text clarifies that.
> 
> Adrian
> 
> > >>>>>> egress NSH will have a new SPI and a SI= 255 or other value, as
stated in
> a).
> > >>>>>> |                |   +    |   +    |       |        |   +   |
|
> > >>>>>> |Classifier      |        |        |       |        |       |
|

---

From: Jim Guichard <[email-masked]>
Date: Sun, 12 Feb 2017 14:07:11 +0000

Hi Adrian,

The point is an SFF does not need to distinguish between receipt of a
packet from an SF or SFF; the suggested text is relevant to a device that
forwards based on NSH and in this architecture only an SFF does that.

Jim
On Sun, Feb 12, 2017 at 5:36 AM Adrian Farrel <[email-masked]> wrote:

> > To: 'Joel M. Halpern' <[email-masked]>; 'Ron Parker'
>
> > <[email-masked]>
>
> > Cc: [email-masked]
>
> > > Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; [email-masked];
>
> > > 'James N Guichard'; 'Fabricio Ferraz'
>
> > > > Does your comment pertain to my somewhat off topic question which
>
> > > > was
>
> > > related to one of Adrian's tangential issues, or to Adrian's original
>
> > > SF=1
>
> > topic?
>
> > > >
>
> > > > Thanks.
>
> > > >
>
> > > >    Ron
>
> > > >
>
> > > >
>
> SG)'
> > > <[email-masked]>; 'Fabricio Ferraz'
>
> > > <[email-masked]>
>
> > > > Personally, what you describe sounds like a quite reasonable case
>
> > > > where a
>
> > > packet arrive at the SF with an SI of 1 will produce exactly the
>
> > > desired
>
> > behavior.
>
> > > >
>
> > > >> * On the other hand, we appear to be clear about an SF that strips
>
> > > >> the NSH
>
> > > >> I'm wondering how to reconcile this to a transparent HTTP Proxy
>
> > > >> that does
>
> > not
>
> > > SF to also be a classifier so it can self-classify its own related
>
> > > flows
>
> > (i.e., using its
>
> > > on the access side are dropped in the upstream direction and injected
>
> > > by the
>
> > SF
>
> > > >> <[email-masked]>; Ron Parker
>
> > <[email-masked]>
>
> > > >> <[email-masked]>; 'Fabricio Ferraz'
>
> > > >> <[email-masked]>
>
> > > >> If this holds then you are correct that sending SI=1 in the first
>
> > > >> case
>
> > requires
>
> > > discard is hardly painful). And it means that SI=1 is a dubious value
> in an
>
> SFP.
>
> > > >>
>
> > > >> Now, does that mean that an SFF should never send a packet with
>
> > > >> SI=1? Well,
>
> > > possibly it is OK for a few specialist SFs intended to sit at the end
>
> > > of the
>
> > chain and
>
> > > >>> Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; [email-masked];
>
> > > >>> 'James N Guichard'; 'Fabricio Ferraz'
>
> > > >>> But you did not suggest whether or not you think that SI=0 should
>
> > > >>> be valid on
>
> > > >> the
>
> > > >>> wire.
>
> > > >>> If I understand Joel correctly, he says we shouldn't send SI=0  in
>
> > > >>> case the
>
> > > >> next
>
> > > >>> So I think this is an unnecessary seat belt, trying to anticipate
>
> > > >>> bugs in
>
> > > >> down-
>
> > > >>> stream devices.
>
> > > >>>
>
> > > >>> I realize the current language has been there a long time, and if
>
> > > >>> it is
>
> > > >> important to
>
> > > >>> Nonetheless, I think devices could safely handle SI=0 on the wire
>
> > > >>> without breaking anything.
>
> > > >>>
>
> > > >>> But I'm not pushing for a change, since the current behavior seems
>
> > > >>> important
>
> > > >> to
>
> > > >>> some.
>
> > > >>>
>
> > > >>> -Dave
>
> > > >>>
>
> > > >>>
>
> > > >>> Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; [email-masked];
>
> > > >>> 'James N Guichard'; 'Fabricio Ferraz'
>
> > > >>> If the SF is not allowed to decrement the SI below zero (which
>
> > > >>> makes
>
> > > >>>> anticipate down-stream devices being misconfigured, one can
>
> > > >>>> invent a lot of
>
> > > >>> silly
>
> > > >>>> requirements.
>
> > > >>>>
>
> > > >>>> >From an aesthetic point of view, I think it's bad that there are
>
> > > >>>>> two SI
>
> > > >>> values (0
>
> > > >>>> And any discussion about buggy SFs... well there is a lot of bad
>
> > > >>>> stuff that
>
> > > >>> bugs can
>
> > > >>>> cause.
>
> > > >>>>
>
> > > >>>>
>
> > > >>>>
>
> > > >>>> Cc: Eric C Rosen; [email-masked]; Dolganow, Andrew (Nokia - SG);
>
> > > >>>> James N
>
> > > >>> Guichard;
>
> > > >>>> Fabricio Ferraz
>
> > > >>>> getting the error in the wrong place, making it harder to
> diagnose and
>
> > repair.
>
> > > >>>>
>
> > > >>>> Yours,
>
> > > >>>> Joel
>
> > > >>>>
>
> > > >>>>> On Feb 9, 2017, at 12:28 PM, Dave Dolson <[email-masked]
>
> > > >>>>> <mailto:[email-masked]>> wrote:
>
> > > >>>>>
>
> > > >>>>>> I agree it should not be sent to an SF, but an SFF could map an
>
> > > >>>>>> SI of zero into a path termination.
>
> > > >>>>>>
>
> > > >>>>>> I.e., the last SF in a path could decrement SI from 1 to 0, and
>
> > > >>>>>> the SFF could then terminate the chain.
>
> > > >>>>>>
>
> > > >>>>>>
>
> > > >>>>>>
>
> > > >>>>>>
>
> > > >>>>>>
>
> > > >>>>>> *From:*sfc [mailto:[email-masked]] *On Behalf Of *James N
>
> > > >>>>>> Guichard
>
> > > >>>>>> <mailto:[email-masked]>>; Dolganow, Andrew (Nokia
>
> > > >>>>>> -
>
> > > >>>>>> given classification result. The initial SI value SHOULD
> default to
>
> 255.
>
> > > >>>>>> a)      Initial SI value should be 255 but other values can be
>
> > > >>>>>> configured by the classifier.
>
> > > >>>>>>
>
> > > >>>>>> èIf SI=1 and there is no re-classification, the egress NSH will
>
> > > >>>>>> have SI=0
>
> > > >>>>>>
>
> > > >>>>>> èIf SI=0 and there is no re-classification the SF should
>
> > > >>>>>> discard the packet
>
> > > >>>>>>
>
> > > >>>>>>
>
> > > >>>>>>
>
> > > >>>>>> *From:*sfc [mailto:[email-masked]] *On Behalf Of *James N
>
> > > >>>>>> Guichard
>
> > > >>>>>> I'm new here (just read the draft last week) but according to
>
> > > >>>>>> chapter
>
> > > >>>>>>   Figure 8 maps each of the four actions above to the
>
> > > >>>>>> components in the
>
> > > >>>>>>
>
> > > >>>>>> |                |  Insert         |Select |   Update
>  |Service
>
> |
>
> > > >>>>>>
>
> > > >>>>>> |                |  or remove NSH  |Service|    NSH
>  |policy
>
> |
>
> > > >>>>>>
>
> > > >>>>>> |                |                 |Function|
>
> |selection|
>
> > > >>>>>>
>
> > > >>>>>> | Component      +--------+--------+Path   +----------------+
>
> |
>
> > > >>>>>>
>
> > > >>>>>> |                |        |        |       | Dec.   |Update |
>
> |
>
> > > >>>>>>
>
> > > >>>>>> |                | Insert | Remove |       |Service |Context|
>
> |
>
> > > >>>>>>
>
> > > >>>>>> |                |        |        |       | Index  |Header |
>
> |
>
> > > >>>>>>
>
> > > >>>>>>
>
> > > >>>>>> |Service Function|        |   +    |  +    |        |       |
>
> |
>
> > > >>>>>>
>
> > > >>>>>> |Forwarder(SFF)  |        |        |       |        |       |
>
> |
>
> > > >>>>>>
>
> > > >>>>>> +---------------
>
> > > >>>>>> |Service         |        |        |       |   +    |   +   |
>  +
> > > >>>>>> |Function  (SF)  |        |        |       |        |       |
>
> |
>
> > > >>>>>>
>
> > > >>>>>> +---------------
>
> > > >>>>>> |SFC Proxy       |   +    |   +    |       |   +    |       |
>
> |
>
> > > >>>>>>
>
> > > >>>>>>
>
> > > >>>>>> receives a NSH packet with SI = 1 that does not necessarily
> means a
>
> > non valid packet.
>
> > > >>>>>>
>
> > > >>>>>> the resulting SI is 0, the SF MUST remove the NSH header before
>
> > > forwarding the packet.
>
> > > >>>>>>
>
> > > >>>>>>
>
> > > >>>>>>
>
> > > >>>>>> Andrew
>
> > > >>>>>>
>
> > > >>>>>> I was never quite happy with the outcome that neither 0 nor 1
>
> > > >>>>>> is a valid SI.
>
> > > >>>>>>
>
> > > >>>>>> (Because if received with value of 1, it is decremented and
>
> > > >>>>>> discarded.)
>
> > > >>>>>>
>
> > > >>>>>>
>
> > > >>>>>>
>
> > > >>>>>> *From:*sfc [mailto:[email-masked]] *On Behalf Of *Eric C
>
> > > >>>>>> Rosen
>
> > > >>>>>> A request was made to be more specific and update the text as
>
> > follows:
>
> > > >>>>>>
>
> > > >>>>>>
>
> > > >>>>>>
>
> SFF"
> > > >>>>>> I think an implication of these procedures is that an SI value
>
> > > >>>>>> of
>

---

From: Ron Parker <[email-masked]>
Date: Sun, 12 Feb 2017 19:24:50 +0000

Jim,

I also consider the (re-)classifier to also make (an initial) forwarding decision based on NSH.

   Ron

On Feb 12, 2017, at 9:07 AM, Jim Guichard <[email-masked]<mailto:[email-masked]>> wrote:

Hi Adrian,

The point is an SFF does not need to distinguish between receipt of a packet from an SF or SFF; the suggested text is relevant to a device that forwards based on NSH and in this architecture only an SFF does that.

Jim
On Sun, Feb 12, 2017 at 5:36 AM Adrian Farrel <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Jim,

So, can we settle on

BTW, I said

existing

and you replied

A

> From: James N Guichard [mailto:[email-masked]<mailto:[email-masked]>]

> To: [email-masked]<mailto:[email-masked]>; 'Joel M. Halpern'; 'Ron Parker'

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

> From: sfc [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Adrian Farrel

> To: 'Joel M. Halpern' <[email-masked]<mailto:[email-masked]>>; 'Ron Parker'

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

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

SI

for

an

discard tail

existing

lookup

> > From: Joel M. Halpern [mailto:[email-masked]<mailto:[email-masked]>]

> > To: Ron Parker; [email-masked]<mailto:[email-masked]>; 'Dave Dolson'

> > Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; [email-masked]<mailto:[email-masked]>;

> > > From: Joel M. Halpern [mailto:[email-masked]<mailto:[email-masked]>]

> > > To: Ron Parker <[email-masked]<mailto:[email-masked]>>;

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

> > 'Dave Dolson' <[email-masked]<mailto:[email-masked]>>

> > > Cc: 'Eric C Rosen' <[email-masked]<mailto:[email-masked]>>; 'Dolganow, Andrew (Nokia - SG)'

> > <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; 'James N Guichard'

> > <[email-masked]<mailto:[email-masked]>>; 'Fabricio Ferraz'

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

> > >> From: Adrian Farrel [mailto:[email-masked]<mailto:[email-masked]>]

> > >> To: 'Dave Dolson' <[email-masked]<mailto:[email-masked]>>; 'Joel M. Halpern'

> > >> <[email-masked]<mailto:[email-masked]>>; Ron Parker

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

> > >> Cc: 'Eric C Rosen' <[email-masked]<mailto:[email-masked]>>; 'Dolganow, Andrew (Nokia -

> > >> SG)' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; 'James N Guichard'

> > >> <[email-masked]<mailto:[email-masked]>>; 'Fabricio Ferraz'

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

> > discard is hardly painful). And it means that SI=1 is a dubious value in an

SFP.

> > >>> From: Dave Dolson [mailto:[email-masked]<mailto:[email-masked]>]

> > >>> To: [email-masked]<mailto:[email-masked]>; 'Joel M. Halpern'; 'Ron Parker'

> > >>> Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; [email-masked]<mailto:[email-masked]>;

> > >>> From: sfc [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Adrian Farrel

> > >>> Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; [email-masked]<mailto:[email-masked]>;

> > >>>> From: sfc [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Dave Dolson

> > >>>> Cc: Fabricio Ferraz; James N Guichard; [email-masked]<mailto:[email-masked]>; Eric C

> > >>>> From: Joel M. Halpern [mailto:[email-masked]<mailto:[email-masked]>]

> > >>>> Cc: Eric C Rosen; [email-masked]<mailto:[email-masked]>; Dolganow, Andrew (Nokia - SG);

> > >>>> getting the error in the wrong place, making it harder to diagnose and

> > >>>>> On Feb 9, 2017, at 12:28 PM, Dave Dolson <[email-masked]<mailto:[email-masked]>

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

> > >>>>>> *From:*sfc [mailto:[email-masked]<mailto:[email-masked]>] *On Behalf Of *James N

> > >>>>>> Dolson; Eric C Rosen; [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>

> > >>>>>> *From:*Fabricio Ferraz [mailto:[email-masked]<mailto:[email-masked]>]

> > >>>>>> *To:* James N Guichard <[email-masked]<mailto:[email-masked]>

> > >>>>>> <mailto:[email-masked]<mailto:[email-masked]>>>; Dolganow, Andrew (Nokia

> > >>>>>> SG) <[email-masked]<mailto:[email-masked]>

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

> > >>>>>> Dolson <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>;

> > >>>>>> Eric C Rosen <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>;

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

> > >>>>>> given classification result. The initial SI value SHOULD default to

255.

stated in

> > >>>>>> *From:*sfc [mailto:[email-masked]<mailto:[email-masked]>] *On Behalf Of *James N

> > >>>>>> Dolson; Eric C Rosen; [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>

> > >>>>>> *From:*Fabricio Ferraz [mailto:[email-masked]<mailto:[email-masked]>]

> > >>>>>> *To:* Dolganow, Andrew (Nokia - SG) <[email-masked]<mailto:[email-masked]>

> > >>>>>> <mailto:[email-masked]<mailto:[email-masked]>>>; Dave Dolson

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

> > >>>>>> <mailto:[email-masked]<mailto:[email-masked]>>>; Eric C Rosen

> > >>>>>> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>; James N

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

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

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

> > >>>>>> |                |  Insert         |Select |   Update       |Service

|

> > >>>>>> |                |  or remove NSH  |Service|    NSH         |policy

|

|selection|

|

|

|

|

|

|

|

|

> > >>>>>> |Service         |        |        |       |   +    |   +   |   +

|

|

|

> > >>>>>> receives a NSH packet with SI = 1 that does not necessarily means a

> > >>>>>> *From:*sfc [mailto:[email-masked]<mailto:[email-masked]>] *On Behalf Of

> > >>>>>> *To:* Dave Dolson; Eric C Rosen; James N Guichard; [email-masked]<mailto:[email-masked]>

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

> > >>>>>> *From: *sfc <[email-masked]<mailto:[email-masked]>

> > >>>>>> <mailto:[email-masked]<mailto:[email-masked]>>> on behalf of Dave Dolson

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

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

> > >>>>>> *To: *Eric Rosen <[email-masked]<mailto:[email-masked]>

> > >>>>>> <mailto:[email-masked]<mailto:[email-masked]>>>, James N Guichard

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

> > >>>>>> <mailto:[email-masked]<mailto:[email-masked]>>>, "[email-masked]<mailto:[email-masked]>

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

> > >>>>>> *From:*sfc [mailto:[email-masked]<mailto:[email-masked]>] *On Behalf Of *Eric C

> > >>>>>> *To:* James N Guichard; [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>

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

sfc mailing list

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 12 Feb 2017 14:56:49 -0500

Ron, I am missing your point.

There are a lot of ways to build a reclassifier.  It can have a 
co-located SFF.  The information that drives the new NSH header content 
can also specify the SFF to send the packet to.
I suppose the reclassifier could do all of its job, then look up in a 
table (not one mandated by the spec) to decide where to sesnd the packet.
However, any reclassifier which produces a packet with an SI of 0 is 
behaving pretty strangely.  Since it is required to send the packet to 
an SFF, it is producing a packet knowing that the packet will be 
immediately dropped, and may produce an error message.

Yours,
Joel

On 2/12/17 2:24 PM, Ron Parker wrote:
>> packet from an SF or SFF; the suggested text is relevant to a device
>> that forwards based on NSH and in this architecture only an SFF does that.
>>
>> Jim
>>     > To: [email-masked] <mailto:[email-masked]>; 'Joel M.
>>     Halpern'; 'Ron Parker'
>>
>>     > Cc: [email-masked] <mailto:[email-masked]>
>>
>>     > From: sfc [mailto:[email-masked]
>>     <mailto:[email-masked]>] On Behalf Of Adrian Farrel
>>
>>     > To: 'Joel M. Halpern' <[email-masked]
>>     <mailto:[email-masked]>>; 'Ron Parker'
>>
>>     > <[email-masked]
>>     <mailto:[email-masked]>>
>>
>>     > Cc: [email-masked] <mailto:[email-masked]>
>>
>>     > > To: Ron Parker; [email-masked]
>>     <mailto:[email-masked]>; 'Dave Dolson'
>>
>>     > > Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)';
>>     [email-masked] <mailto:[email-masked]>;
>>
>>     > > > To: Ron Parker <[email-masked]
>>     <mailto:[email-masked]>>;
>>
>>     > > > [email-masked] <mailto:[email-masked]>;
>>
>>     > > 'Dave Dolson' <[email-masked] <mailto:[email-masked]>>
>>
>>     > > > Cc: 'Eric C Rosen' <[email-masked]
>>     <mailto:[email-masked]>>; 'Dolganow, Andrew (Nokia - SG)'
>>
>>     > > <[email-masked]
>>     <mailto:[email-masked]>>; [email-masked]
>>     <mailto:[email-masked]>; 'James N Guichard'
>>
>>     <mailto:[email-masked]>>; 'Fabricio Ferraz'
>>
>>     > > <[email-masked] <mailto:[email-masked]>>
>>
>>     > > >> To: 'Dave Dolson' <[email-masked]
>>     <mailto:[email-masked]>>; 'Joel M. Halpern'
>>
>>     > > >> <[email-masked] <mailto:[email-masked]>>; Ron Parker
>>
>>     > <[email-masked]
>>     <mailto:[email-masked]>>
>>
>>     > > >> Cc: 'Eric C Rosen' <[email-masked]
>>     <mailto:[email-masked]>>; 'Dolganow, Andrew (Nokia -
>>
>>     > > >> SG)' <[email-masked]
>>     <mailto:[email-masked]>>; [email-masked]
>>     <mailto:[email-masked]>; 'James N Guichard'
>>
>>     <mailto:[email-masked]>>; 'Fabricio Ferraz'
>>
>>     > > >>> To: [email-masked] <mailto:[email-masked]>;
>>     'Joel M. Halpern'; 'Ron Parker'
>>
>>     > > >>> Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)';
>>     [email-masked] <mailto:[email-masked]>;
>>
>>     > > >>> From: sfc [mailto:[email-masked]
>>     <mailto:[email-masked]>] On Behalf Of Adrian Farrel
>>
>>     > > >>> Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)';
>>     [email-masked] <mailto:[email-masked]>;
>>
>>     > > >>>> From: sfc [mailto:[email-masked]
>>     <mailto:[email-masked]>] On Behalf Of Dave Dolson
>>
>>     > > >>>> Cc: Eric C Rosen; [email-masked] <mailto:[email-masked]>;
>>     Dolganow, Andrew (Nokia - SG);
>>
>>     > > >>>> James N
>>
>>     > > >>> Guichard;
>>
>>     > > >>>> Fabricio Ferraz
>>
>>     > > >>>>> On Feb 9, 2017, at 12:28 PM, Dave Dolson
>>     <[email-masked] <mailto:[email-masked]>
>>
>>     > > >>>>>> *From:*sfc [mailto:[email-masked]
>>     <mailto:[email-masked]>] *On Behalf Of *James N
>>
>>     > > >>>>>> Guichard
>>
>>     > > >>>>>> Dolson; Eric C Rosen; [email-masked]
>>     <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>>
>>     > > >>>>>> *From:*Fabricio Ferraz
>>     [mailto:[email-masked]
>>     <mailto:[email-masked]>]
>>
>>     <mailto:[email-masked]>
>>
>>     > > >>>>>> <mailto:[email-masked]
>>     <mailto:[email-masked]>>>; Dolganow, Andrew (Nokia
>>
>>     > > >>>>>> -
>>
>>     <mailto:[email-masked]>
>>
>>     > > >>>>>> Dolson <[email-masked]
>>     <mailto:[email-masked]> <mailto:[email-masked]
>>     <mailto:[email-masked]>>>;
>>
>>     > > >>>>>> Eric C Rosen <[email-masked]
>>     <mailto:[email-masked]> <mailto:[email-masked]
>>     <mailto:[email-masked]>>>;
>>
>>     > > >>>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>>     <mailto:[email-masked]>>
>>
>>     > > >>>>>> *From:*sfc [mailto:[email-masked]
>>     <mailto:[email-masked]>] *On Behalf Of *James N
>>
>>     > > >>>>>> Guichard
>>
>>     > > >>>>>> Dolson; Eric C Rosen; [email-masked]
>>     <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>>
>>     > > >>>>>> *From:*Fabricio Ferraz
>>     [mailto:[email-masked]
>>     <mailto:[email-masked]>]
>>
>>     > > >>>>>> *To:* Dolganow, Andrew (Nokia - SG)
>>     <[email-masked] <mailto:[email-masked]>
>>
>>     > > >>>>>> <mailto:[email-masked]
>>     <mailto:[email-masked]>>>; Dave Dolson
>>
>>     > > >>>> <[email-masked] <mailto:[email-masked]>
>>
>>     > > >>>>>> <mailto:[email-masked]
>>     <mailto:[email-masked]>>>; Eric C Rosen
>>
>>     > > >>>>>> <[email-masked] <mailto:[email-masked]>
>>     <mailto:[email-masked] <mailto:[email-masked]>>>; James N
>>
>>     <mailto:[email-masked]>
>>
>>     > > >>>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>>     <mailto:[email-masked]>>
>>
>>     > > >>>>>> |                |        |        |       | Dec.
>>      |Update |
>>     > > >>>>>> |                |        |        |       | Index
>>     |Header |
>>     > > >>>>>> |                |   +    |   +    |       |        |
>>      +   |
>>     > > >>>>>> |Classifier      |        |        |       |        |
>>     > > >>>>>> *From:*sfc [mailto:[email-masked]
>>     <mailto:[email-masked]>] *On Behalf Of
>>
>>     > > >>>>>> *To:* Dave Dolson; Eric C Rosen; James N Guichard;
>>     > > >>>>>> <mailto:[email-masked] <mailto:[email-masked]>>
>>
>>     <mailto:[email-masked]>
>>
>>     > > >>>>>> <mailto:[email-masked]
>>     <mailto:[email-masked]>>> on behalf of Dave Dolson
>>
>>     > > >>>>>> <[email-masked] <mailto:[email-masked]>
>>
>>     > > >>>> <mailto:[email-masked] <mailto:[email-masked]>>>
>>
>>     <mailto:[email-masked]>
>>
>>     > > >>>>>> <mailto:[email-masked]
>>     <mailto:[email-masked]>>>, James N Guichard
>>
>>     <mailto:[email-masked]>
>>
>>     > > >>>>>> <mailto:[email-masked]
>>     <mailto:[email-masked]>>>, "[email-masked]
>>     <mailto:[email-masked]>
>>
>>     > > >>>>>> <mailto:[email-masked] <mailto:[email-masked]>>"
>>     <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>>     <mailto:[email-masked]>>>
>>
>>     > > >>>>>> *From:*sfc [mailto:[email-masked]
>>     <mailto:[email-masked]>] *On Behalf Of *Eric C
>>
>>     > > >>>>>> Rosen
>>
>>     > > >>>>>> *To:* James N Guichard; [email-masked]
>>     <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>>
>>     > > >>>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>>     <mailto:[email-masked]>>
>>

---

From: Ron Parker <[email-masked]>
Date: Sun, 12 Feb 2017 19:59:06 +0000

Joel,

I was only referring to Jim's assertion that in the SFC architecture only SFF forwards based on NSH.  

   Ron

> On Feb 12, 2017, at 2:56 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> There are a lot of ways to build a reclassifier.  It can have a co-located SFF.  The information that drives the new NSH header content can also specify the SFF to send the packet to.
> I suppose the reclassifier could do all of its job, then look up in a table (not one mandated by the spec) to decide where to sesnd the packet.
> However, any reclassifier which produces a packet with an SI of 0 is behaving pretty strangely.  Since it is required to send the packet to an SFF, it is producing a packet knowing that the packet will be immediately dropped, and may produce an error message.
> 
> Yours,
> Joel
> 
>>>    <mailto:[email-masked]>>> wrote:
>>> 
>>>    > > >>>>>
>>> 
>>>    <mailto:[email-masked]>>>;
>>> 
>>>    > > >>>> Dave
>>> 
>>>    > > >>>>>> ?If SI=1 and there is no re-classification, the egress
>>>    NSH will
>>> 
>>>    > > >>>>>> have SI=0
>>> 
>>>    > > >>>>>>
>>> 
>>>    > > >>>>>> ?If SI=0 and there is re-classification with new SPI, the
>>> 
>>>    > > >>>>>> ?If SI=0 and there is no re-classification the SF should
>>> 
>>>    > > >>>>>> discard the packet
>>> 
>>>    > > >>>>>>
>>> 
>>>    > > >>>>>>
>>> 
>>>    > > >>>>>>
>>> 
>>>    <mailto:[email-masked]>>>;
>>>

---

From: Jim Guichard <[email-masked]>
Date: Sun, 12 Feb 2017 20:07:20 +0000

Which is true ;-) .. a classifier *imposes* NSH which is not forwarding
based on SPI/SI although you *could* co-locate SFF forwarding with the
classifier.

Jim
On Sun, Feb 12, 2017 at 2:59 PM Ron Parker <[email-masked]>
wrote:

> co-located SFF.  The information that drives the new NSH header content can
> also specify the SFF to send the packet to.
>
> behaving pretty strangely.  Since it is required to send the packet to an
> SFF, it is producing a packet knowing that the packet will be immediately
> dropped, and may produce an error message.
>
> >
>
> > Yours,
>
> > Joel
>
> >
>
> >> I also consider the (re-)classifier to also make (an initial) forwarding
>
> >> decision based on NSH.
>
> >>
>
> >>   Ron
>
> >>
>
> >> On Feb 12, 2017, at 9:07 AM, Jim Guichard <[email-masked]
>
> >> <mailto:[email-masked]>> wrote:
>
> >>
>
> >>> Hi Adrian,
>
> >>>
>
> >>> On Sun, Feb 12, 2017 at 5:36 AM Adrian Farrel <[email-masked]
>
> >>> <mailto:[email-masked]>> wrote:
>
> >>>
>
> >>>    Thanks Jim,
>
> >>>
>
> >>>
>
> >>>
>
> >>>    Your text works for me although I would prefer to delete the
>
> >>>    commentary about a
>
> >>>
>
> >>>    "broken SFC" as a specific example of how this might happen that
>
> >>>    is not the only
>
> >>>
>
> >>>    "Packets received at an SFF with an SI of zero MUST be discarded
>
> >>>    and the SFF
>
> >>>
>
> >>>    >> Then (of course) it is also OK for an SFF to receive SI=0, but
>
> >>>    I think the
>
> >>>
>
> >>>    existing
>
> >>>
>
> >>>    Since an SFF cannot tell the difference between a packet received
>
> >>>    from an SFF
>
> >>>
>
> >>>    > From: James N Guichard [mailto:[email-masked]
>
> >>>    <mailto:[email-masked]>]
>
> >>>
>
> >>>    > Jim> the above text is perhaps what is causing some confusion as
>
> >>>    it implies an
>
> >>>
>
> >>>    SI
>
> >>>
>
> >>>    > of 0 from an SF is invalid. May I suggest the following text as
>
> >>>    a replacement
>
> >>>
>
> >>>    for
>
> >>>
>
> >>>    > the above sentence:
>
> >>>
>
> >>>    >
>
> >>>
>
> >>>    > "The value zero for SI indicates a broken SFC. Packets received
>
> >>>    at an SFF with
>
> >>>
>
> >>>    an
>
> >>>
>
> >>>    > SI of zero MUST be discarded and the SFF SHOULD generate an
>
> >>>    error/log
>
> >>>
>
> >>>    > message".
>
> >>>
>
> >>>    >
>
> >>>
>
> >>>    > I can't tell whether the former is really true or, perhaps,
>
> >>>    represents a
>
> >>>
>
> >>>    discard tail
>
> >>>
>
> >>>    > Then (of course) it is also OK for an SFF to receive SI=0, but I
>
> >>>    think the
>
> >>>
>
> >>>    existing
>
> >>>
>
> >>>    > Jim> from an SF yes but not from another SFF. However, in either
>
> >>>    case, a
>
> >>>
>
> >>>    lookup
>
> >>>
>
> >>>    > on <SPI><SI=0> should cause the SFF to discard the packet.
>
> >>>    Hopefully my above
>
> >>>
>
> >>>    > > From: Joel M. Halpern [mailto:[email-masked]
>
> >>>    <mailto:[email-masked]>]
>
> >>>
>
> >>>    > > I was commenting, in personal hat, about the issue of whether
>
> >>>    there
>
> >>>
>
> >>>    > > was some sort of problem with the impact of the current
>
> >>>    description on
>
> >>>
>
> >>>    > > It will also sometimes produce packet drops by the SFF, when
>
> >>>    the SF
>
> >>>
>
> >>>    > > It is not even clear there is anything, in Adrian's phrase, to
>
> >>>    paint
>
> >>>
>
> >>>    > > red here.
>
> >>>
>
> >>>    > >
>
> >>>
>
> >>>    > > Yours,
>
> >>>
>
> >>>    > > Joel
>
> >>>
>
> >>>    > >
>
> >>>
>
> >>>    > > > Does your comment pertain to my somewhat off topic question
>
> >>>    which
>
> >>>
>
> >>>    > > > was
>
> >>>
>
> >>>    > > related to one of Adrian's tangential issues, or to Adrian's
>
> >>>    original
>
> >>>
>
> >>>    > > SF=1
>
> >>>
>
> >>>    > topic?
>
> >>>
>
> >>>    > > >
>
> >>>
>
> >>>    > > > Thanks.
>
> >>>
>
> >>>    > > >
>
> >>>
>
> >>>    > > >    Ron
>
> >>>
>
> >>>    > > >
>
> >>>
>
> >>>    > > >
>
> >>>
>
> >>>    > > > From: Joel M. Halpern [mailto:[email-masked]
>
> >>>    <mailto:[email-masked]>]
>
> >>>
>
> >>>    > > <[email-masked] <mailto:[email-masked]
> >>
>
> >>>
>
> >>>    > > > Personally, what you describe sounds like a quite reasonable
>
> >>>    case
>
> >>>
>
> >>>    > > > where a
>
> >>>
>
> >>>    > > > Which suggests, to my limited view, that the current text
>
> >>>    works fine.
>
> >>>
>
> >>>    > > >
>
> >>>
>
> >>>    > > > Yours,
>
> >>>
>
> >>>    > > > Joel
>
> >>>
>
> >>>    > > >
>
> >>>
>
> >>>    > > >> * On the other hand, we appear to be clear about an SF that
>
> >>>    strips
>
> >>>
>
> >>>    > > >> the NSH
>
> >>>
>
> >>>    > > preserve the original source-IP?   Does this mean that it is
>
> >>>    mandatory for
>
> >>>
>
> >>>    > such an
>
> >>>
>
> >>>    > > own visible IP addresses)?    From SFF perspective, it would
>
> >>>    look like all
>
> >>>
>
> >>>    > packets
>
> >>>
>
> >>>    > > on the access side are dropped in the upstream direction and
>
> >>>    injected
>
> >>>
>
> >>>    > > by the
>
> >>>
>
> >>>    > SF
>
> >>>
>
> >>>    > > in the downstream direction.   On the Internet side, it would
>
> >>>    look like all
>
> >>>
>
> >>>    > packets
>
> >>>
>
> >>>    > > are injected by the SF in the upstream direction and dropped
>
> >>>    in the
>
> >>>
>
> >>>    > > downstream direction.
>
> >>>
>
> >>>    > > >>
>
> >>>
>
> >>>    > > >> From: Adrian Farrel [mailto:[email-masked]
>
> >>>    <mailto:[email-masked]>]
>
> >>>
>
> >>>    > > >> <[email-masked]
>
> >>>    <mailto:[email-masked]>>
>
> >>>
>
> >>>    > > >> Some have said that there must be no visible difference
>
> >>>    between the
>
> >>>
>
> >>>    > > >> three
>
> >>>
>
> >>>    > > case:
>
> >>>
>
> >>>    > > >> If this holds then you are correct that sending SI=1 in the
>
> >>>    first
>
> >>>
>
> >>>    > > >> case
>
> >>>
>
> >>>    > requires
>
> >>>
>
> >>>    > > discard is hardly painful). And it means that SI=1 is a
>
> >>>    dubious value in an
>
> >>>
>
> >>>    SFP.
>
> >>>
>
> >>>    > > >>
>
> >>>
>
> >>>    > > >> On the other hand, we appear to be clear about an SF that
>
> >>>    strips
>
> >>>
>
> >>>    > > >> the NSH
>
> >>>
>
> >>>    > and
>
> >>>
>
> >>>    > > forwards the traffic as native : this is currently forbidden.
>
> >>>    So there
>
> >>>
>
> >>>    > > is no alternative for an SF receiving SI=1 except to discard
>
> >>>    the packet.
>
> >>>
>
> >>>    > > >>
>
> >>>
>
> >>>    > > possibly it is OK for a few specialist SFs intended to sit at
>
> >>>    the end
>
> >>>
>
> >>>    > > of the
>
> >>>
>
> >>>    > chain and
>
> >>>
>
> >>>    > > be a bit bucket with analysis. But, for most SFs there would
>
> >>>    be no point.
>
> >>>
>
> >>>    > > >>
>
> >>>
>
> >>>    > > decide on the functional behavior we want to see and then
>
> >>>    design the
>
> >>>
>
> >>>    > > protocol to match.
>
> >>>
>
> >>>    > > >>
>
> >>>
>
> >>>    > > >> Adrian
>
> >>>
>
> >>>    > > >>
>
> >>>
>
> >>>    > > >>> From: Dave Dolson [mailto:[email-masked]
>
> >>>    <mailto:[email-masked]>]
>
> >>>
>
> >>>    > > >>> But you did not suggest whether or not you think that SI=0
>
> >>>    should
>
> >>>
>
> >>>    > > >>> be valid on
>
> >>>
>
> >>>    > > >> the
>
> >>>
>
> >>>    > > >>> wire.
>
> >>>
>
> >>>    > > >>> If I understand Joel correctly, he says we shouldn't send
>
> >>>    SI=0  in
>
> >>>
>
> >>>    > > >>> case the
>
> >>>
>
> >>>    > > >> next
>
> >>>
>
> >>>    > > >>> --> this seems to mean SI=1 cannot be used except at the
>
> >>>    terminus
>
> >>>
>
> >>>    > > >>> --> or when the
>
> >>>
>
> >>>    > > >>> So I think this is an unnecessary seat belt, trying to
>
> >>>    anticipate
>
> >>>
>
> >>>    > > >>> bugs in
>
> >>>
>
> >>>    > > >> down-
>
> >>>
>
> >>>    > > >>> stream devices.
>
> >>>
>
> >>>    > > >>>
>
> >>>
>
> >>>    > > >>> I realize the current language has been there a long time,
>
> >>>    and if
>
> >>>
>
> >>>    > > >>> it is
>
> >>>
>
> >>>    > > >> important to
>
> >>>
>
> >>>    > > >>> Nonetheless, I think devices could safely handle SI=0 on
>
> >>>    the wire
>
> >>>
>
> >>>    > > >>> But I'm not pushing for a change, since the current
>
> >>>    behavior seems
>
> >>>
>
> >>>    > > >>> important
>
> >>>
>
> >>>    > > >> to
>
> >>>
>
> >>>    > > >>> some.
>
> >>>
>
> >>>    > > >>>
>
> >>>
>
> >>>    > > >>> -Dave
>
> >>>
>
> >>>    > > >>>
>
> >>>
>
> >>>    > > >>>
>
> >>>
>
> >>>    > > >>> We're building a protocol. with a protocol, you cannot
>
> >>>    (must not)
>
> >>>
>
> >>>    > > >>> Since SFs are allowed to drop packets (indeed that is one
>
> >>>    of their
>
> >>>
>
> >>>    > > >>> main jobs
>
> >>>
>
> >>>    > > >> ;-)
>
> >>>
>
> >>>    > > >>> then this would be fine.
>
> >>>
>
> >>>    > > >>> All that would be left is to define whether they apply the
>
> >>>    test
>
> >>>
>
> >>>    > > >>> before or
>
> >>>
>
> >>>    > > >> after
>
> >>>
>
> >>>    > > >>> normal processing.
>
> >>>
>
> >>>    > > >>>
>
> >>>
>
> >>>    > > >>> As an aside, I agree with Don that TTL helps relax this a
>
> >>>    little,
>
> >>>
>
> >>>    > > >>>> Cc: Fabricio Ferraz; James N Guichard; [email-masked]
>
> >>>    <mailto:[email-masked]>; Eric C
>
> >>>
>
> >>>    > > >>>> Discussing misconfigured SFFs is a straw-man argument.
>
> >>>    Once one
>
> >>>
>
> >>>    > > >>>> starts
>
> >>>
>
> >>>    > > >> trying
>
> >>>
>
> >>>    > > >>> to
>
> >>>
>
> >>>    > > >>>> >From an aesthetic point of view, I think it's bad that
>
> >>>    there are
>
> >>>
>
> >>>    > > >>>>> two SI
>
> >>>
>
> >>>    > > >>> values (0
>
> >>>
>
> >>>    > > >>>> And any discussion about buggy SFs... well there is a lot
>
> >>>    of bad
>
> >>>
>
> >>>    > > >>>> stuff that
>
> >>>
>
> >>>    > > >>> bugs can
>
> >>>
>
> >>>    > > >>>> cause.
>
> >>>
>
> >>>    > > >>>>
>
> >>>
>
> >>>    > > >>>>
>
> >>>
>
> >>>    > > >>>>
>
> >>>
>
> >>>    > > >>>> From: Joel M. Halpern [mailto:[email-masked]
>
> >>>    <mailto:[email-masked]>]
>
> >>>
>
> >>>    > > >>>>  From my perspective as an individual participant in this
>
> >>>    work,
>
> >>>
>
> >>>    > > >>>> mis-configured SFF could easily continue processing such
>
> >>>    a packet.
>
> >>>
>
> >>>    > > >>>> Now, it is true that TTL will eventually drop it, but
>
> >>>    that is an
>
> >>>
>
> >>>    > expensive
>
> >>>
>
> >>>    > > fallback.
>
> >>>
>
> >>>    > > >>>>
>
> >>>
>
> >>>    > > >>>> More importantly, presumably the next entitiy down the
>
> >>>    incorrect
>
> >>>
>
> >>>    > > >>>>>> I'm not clear on why this is broken, or why this
>
> >>>    restriction is made.
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>> I agree it should not be sent to an SF, but an SFF
>
> >>>    could map an
>
> >>>
>
> >>>    > > >>>>>> I.e., the last SF in a path could decrement SI from 1
>
> >>>    to 0, and
>
> >>>
>
> >>>    > > >>>>>> Not exactly. Section 3.3 specifies "The value zero for
>
> >>>    SI is
>
> >>>
>
> >>>    > > >>>>>> not valid and indicates a broken SFC or malfunctioning
>
> >>>    SF" ..
>
> >>>
>
> >>>    > > >>>>>> In other words an SF should never receive an NSH packet
>
> >>>    with SI = 0.
>
> >>>
>
> >>>    > > >>>>>> Note that if this happened then either a) a classifier
>
> >>>    set the
>
> >>>
>
> >>>    > > >>>>>> SI incorrectly, or b) a re-classifier set the SI
>
> >>>    incorrectly,
>
> >>>
>
> >>>    > > >>>>>> or c) an upstream SF set the SI incorrectly; all of
>
> >>>    these cases
>
> >>>
>
> >>>    > > >>>>>> given classification result. The initial SI value
>
> >>>    SHOULD default to
>
> >>>
>
> >>>    255.
>
> >>>
>
> >>>    > > >>>>>> However, the classifier MUST allow configuration of
>
> >>>    other SI values.
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>> Service Index MUST be decremented by Service Functions
>
> >>>    or by
>
> >>>
>
> >>>    > > >>>>>> SFC Proxy nodes after performing required services and
>
> >>>    the new
>
> >>>
>
> >>>    > > >>>>>> The initial Classifier MUST send the packet to the
>
> >>>    first SFF in
>
> >>>
>
> >>>    > > >>>>>> If re-classification occurs, and that re-classification
>
> >>>    results
>
> >>>
>
> >>>    > > >>>>>> a)      Initial SI value should be 255 but other values
>
> >>>    can be
>
> >>>
>
> >>>    > > >>>>>> c)       If re-classification occurs with new SPI, the
>
> >>>    re-classifier
>
> >>>
>
> >>>    > > >>>>>> is the initial classifier, so by  a), SI should be
>
> >>>    again 255 or
>
> >>>
>
> >>>    > > >>>>>> other value
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>> So any SI value can be receive by an SF, even 1 or 0
>
> >>>    because:
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>> egress NSH will have a new SPI and a SI= 255 or other
>
> >>>    value, as
>
> >>>
>
> >>>    stated in
>
> >>>
>
> >>>    > a).
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>> Also an SFF should forward/handle packets with NSH with
>
> >>>    SI=1 or SI=0.
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>> Do you agree?
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>> re-classifier (section 4, bullet point 1 lays this
>
> >>>    out). With
>
> >>>
>
> >>>    > > >>>>>> the current architecture the SF does not care what SI
>
> >>>    value it
>
> >>>
>
> >>>    > > >>>>>> gets, it just needs to worry about decrementing it, and
>
> >>>    leave
>
> >>>
>
> >>>    > > >>>>>> it up to the SFF to evaluate the SI value and
>
> >>>    associated action.
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>> Jim
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>> *From:*Fabricio Ferraz
>
> >>>    > > >>>>>> I'm new here (just read the draft last week) but
>
> >>>    according to
>
> >>>
>
> >>>    > > >>>>>> chapter
>
> >>>
>
> >>>    > > >>>>>> 4 (check figure 8 for example), an SF is not allowed to
>
> >>>    insert
>
> >>>
>
> >>>    > > >>>>>> or remove NSH. The removal of NSH is reponsability of
>
> >>>    the SSF, right?
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>> | Component      +--------+--------+Path
>
> >>>     +----------------+
>
> >>>
>
> >>>    |
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>> |                |        |        |       | Dec.
>
> >>>     |Update |
>
> >>>
>
> >>>    |
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>> |                | Insert | Remove |       |Service
>
> >>>    |Context|
>
> >>>
>
> >>>    |
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>> |                |        |        |       | Index
>
> >>>    |Header |
>
> >>>
>
> >>>    |
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>
> >>>    > > >>>>>> |Service Function|        |   +    |  +    |        |
>
> >>>         |
>
> >>>
>
> >>>    |
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>> |Forwarder(SFF)  |        |        |       |        |
>
> >>>         |
>
> >>>
>
> >>>    |
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>> +---------------
>
> >>>
>
> >>>    > > >>>>>> |Service         |        |        |       |   +    |
> >>>     +   |   +
> >>>    > > >>>>>> |Function  (SF)  |        |        |       |        |
> >>>    > > >>>>>> |SFC Proxy       |   +    |   +    |       |   +    |
>
> >>>         |
>
> >>>
>
> >>>    |
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>
> >>>    > > >>>>>> reclassify it to a different SPI and SI, right? So when
>
> >>>    a SF
>
> >>>
>
> >>>    > > >>>>>> receives a NSH packet with SI = 1 that does not
>
> >>>    necessarily means a
>
> >>>
>
> >>>    > non valid packet.
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>> And that can even work for SI=0, since you decrement
>
> >>>    the SI in
>
> >>>
>
> >>>    > > >>>>>> the
>
> >>>
>
> >>>    > > >> egress.
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>> Fabricio
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>> An SF or SFC Proxy receiving an NSH-encapsulated packet
>
> >>>    MUST
>
> >>>
>
> >>>    > > >>>>>> processing and before forwarding the packet to the next
>
> >>>    SFF. If
>
> >>>
>
> >>>    > > >>>>>> the resulting SI is 0, the SF MUST remove the NSH
>
> >>>    header before
>
> >>>
>
> >>>    > > forwarding the packet.
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>> Andrew
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>> <mailto:[email-masked] <mailto:[email-masked]
> >>>
>
> >>>
>
> >>>    > > >>>>>> I was never quite happy with the outcome that neither 0
>
> >>>    nor 1
>
> >>>
>
> >>>    > > >>>>>> is a valid SI.
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>> I guess I'm interested to know if that is important to
>
> >>>    other
>
> >>>
>
> >>>    > > >>>>>> A request was made to be more specific and update the
>
> >>>    text as
>
> >>>
>
> >>>    > follows:
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>> "Service index MUST be decremented *by a value of 1* by
>
> >>>    Service
>
> >>>
>
> >>>    > > >>>>>> Functions or by SFC Proxy nodes after performing
>
> >>>    required services ."
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>> - The term "SFC Proxy node" is not defined in either
>
> >>>    the NSH
>
> >>>
>
> >>>    > > >>>>>> - Is the intention that the SI remain unchanged while
>
> >>>    the SF is
>
> >>>
>
> >>>    > > >>>>>> operating on the packet, or is the intention only that
>
> >>>    the SI
>
> >>>
>
> >>>    > > >>>>>> be decremented before the packet is delivered by the SF
>
> >>>    or SFC
>
> >>>
>
> >>>    > > >>>>>> Proxy to an SFF?
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>> I'd suggest either:
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>> "An SF or SFC Proxy receiving an NSH-encapsulated
>
> >>>    packet MUST
>
> >>>
>
> >>>    > > >>>>>> decrement the SI by 1 before delivering the packet to
>
> >>>    the next SFF"
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>> or
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>> "An SF or SFC Proxy receiving an NSH-encapsulated
>
> >>>    packet MUST
>
> >>>
>
> >>>    > > >>>>>> decrement the SI by 1 before delivering the packet to
>
> >>>    the next
>
> >>>
>
> >>>    > > >>>>>> SFF, but not until the SF has finished all its other
>
> >>>    processing
>
> >>>
>
> >>>    > > >>>>>> of the
>
> >>>
>
> >>>    > > packet"
>
> >>>
>
> >>>    > > >>>>>>
>
> >>>
>
> >>>    > > >>>>>> I think an implication of these procedures is that an
>
> >>>    SI value
>
> >>>
>
> >>>    > > >>>>>> of
>
> >>>
>
> >>>    > > >>>>>> 1 is not valid.  If an SF gets an NSH packet with an SI
>
> >>>    of 1,
>
> >>>
>
> >>>    > > >>>>>> the SF will decrement the SI (setting it to 0), send
>
> >>>    the packet
>
> >>>
>
> >>>    > > >>>>>> to an SFF, and the SFF will discard it, because 0 is an
>
> >>>    invalid
>
> >>>
>
> >>>    > > >>>>>> discard a packet with an SI of 0, but does not seem to
>
> >>>    say that
>
> >>>
>
> >>>    > > >>>>>> an SF or SFC Proxy should discard a packet it receives
>
> >>>    with an
>
> >>>
>
> >>>    > > >>>>>> Some text in the draft (e.g., section 7.1) states than
>
> >>>    an SFF
>
> >>>
>
> >>>    > > >>>>>> should discard a packet with an SI of zero, but other
>
> >>>    text in
>
> >>>
>
> >>>    > > >>>>>> the draft (e.g., section 3.3) only says that an SFF
>
> >>>    should log
>
> >>>
>
> >>>    > > >>>>>> change the text in 3.3. to say "SHOULD generate an
>
> >>>    error/log
>
> >>>
>