Subject: Re: [sfc] NSH Service Index Decrement

From: "jmh.direct" <[email-masked]>
Date: Thu, 09 Feb 2017 15:58:19 -0500

Legal?  Sure.  The SF has done it's job right.The SFF will then discard the packet.  Unless there is a reclassified between the SF and the SFF.
Allowing an SFF to serve as egress for a packet with SI 0 requires more complex checking and is less robust.  Sure, it can be made to work.  Is there a real need to allow it?
Yours,Joel

Sent via the Samsung Galaxy S® 6, an AT&T 4G LTE smartphone
-------- Original message --------From: "Fedyk, Don" <[email-masked]> Date: 2/9/17  15:38  (GMT-05:00) To: "Joel M. Halpern" <[email-masked]>, 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]> Subject: RE: [sfc] NSH Service Index Decrement 
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]>
> Subject: Re: [sfc] NSH Service Index Decrement
> 
>  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:
> > 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.
> >>
> >>
> >>
> >>
> >>
> >> *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] <mailto:[email-masked]>
> >> *Subject:* Re: [sfc] NSH Service Index Decrement
> >>
> >>
> >>
> >> 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]
> >> <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.
> >>
> >>
> >>
> >> 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] <mailto:[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?
> >>
> >>
> >>
> >>   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]
> >> <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.
> >>
> >>
> >>
> >> 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] <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 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] <mailto:[email-masked]>
> >> *Subject:* Re: [sfc] NSH Service Index Decrement
> >>
> >>
> >>
> >> On 2/7/2017 2:24 PM, James N Guichard wrote:
> >>
> >> 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 ."
> >>
> >>
> >> 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.
> >>
> >> _______________________________________________
> >> sfc mailing list
> >> [email-masked] <mailto:[email-masked]>
> >> https://www.ietf.org/mailman/listinfo/sfc
> >
> >
> > _______________________________________________
> > sfc mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/sfc
> >
> 
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

---

From: "jmh.direct" <[email-masked]>
Date: Sat, 11 Feb 2017 17:45:04 -0500

Those clarifications seem accurate and useful to me.  
Yours,Joel

Sent via the Samsung Galaxy S® 6, an AT&T 4G LTE smartphone
-------- Original message --------From: Adrian Farrel <[email-masked]> Date: 2/11/17  17:35  (GMT-05:00) To: "'Joel M. Halpern'" <[email-masked]>, 'Ron Parker' <[email-masked]> Cc: [email-masked] Subject: RE: [sfc] NSH Service Index Decrement 
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

> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: 11 February 2017 18:08
> To: Ron Parker; [email-masked]; 'Dave Dolson'
> Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; [email-masked]; 'James N
> Guichard'; 'Fabricio Ferraz'
> 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
> 
> On 2/11/17 12:59 PM, Ron Parker wrote:
> > 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?
> >    Ron
> > 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]>
> > 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
> >
> > On 2/11/17 11:55 AM, Ron Parker wrote:
> >> 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
> >>
> >>
> >>
> >> 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
> >>
> >> 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'
> >>> Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; [email-masked];
> >>> 'James N Guichard'; 'Fabricio Ferraz'
> >>> Subject: RE: [sfc] NSH Service Index Decrement
> >>>
> >>> 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
> >>>
> >>>
> >>> 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'
> >>> 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
> >>>
> >>>> From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
> >>>> 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.
> >>>>
> >>>> 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.
> >>>>
> >>>>
> >>>>
> >>>> From: Joel M. Halpern [mailto:[email-masked]]
> >>>> To: Ron Parker; Dave Dolson
> >>>> Cc: Eric C Rosen; [email-masked]; Dolganow, Andrew (Nokia - SG); James
> >>>> N
> >>> Guichard;
> >>>> Fabricio Ferraz
> >>>>  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
> >>>>
> >>>>>> 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.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> 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.
> >>>>>> <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=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
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> 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
> >>>>>>
> >>>>>>
> >>>>>>
> >>>> <[email-masked]
> >>>>>> <mailto:[email-masked]>>; Eric C Rosen <[email-masked]
> >>>>>> <mailto:[email-masked]>>; James N Guichard
> >>>>>>   Figure 8 maps each of the four actions above to the components
> >>>>>> in the
> >>>>>>
> >>>>>> 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.
> >>>>>>
> >>>>>> 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]
> >>>>>> *To: *Eric Rosen <[email-masked]
> >>>>>> <mailto:[email-masked]>>, James N Guichard
> >>>>>> <[email-masked]
> >>>>>> I was never quite happy with the outcome that neither 0 nor 1 is
> >>>>>> a valid SI.
> >>>>>>
> >>>>>> - 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.
> >>>>>>