Re: [sfc] TTL field within the NSH base header

["Joel M. Halpern" <[e-mail]>]

Speaking personally in the following:
If we have an SFF that manages to decrement the TTL field, but then 
fails to test it against 0, yes, the loop will not break there.  Unless 
the loop is exactly 64 so that the detection comes back to the very 
oddly broken device, it will still get broken later.  Which is all we 
really ask.

Ther eis a limit to how many mis-behaviors we can allow for.  If a 
Router were to reset the IP TTL field to max, that would destroy loop 
prevention too.  So what?

I would like to keep this very simple, and avoid knobs that we do not 
need.  Allowing 0 incoming everywhere, and decrementing it to 63, seems 
simple and consistent.  It avoids needing configuration.  It allows the 
front of an SFP to be existing devices withotu needing any configuration.
And the overall behavior allows existing devices at other places in the 
path.


Yours,
Joel

On 5/2/17 8:52 AM, [e-mail] wrote:
> Re-,
>
>
>
> You have a point. Acked.
>
>
>
> My concern was how to avoid misbehaving SFFs that would forward packets
> with SHL==0 to a next-hop SFF even if that SFF parses the SHL field.
>
>
>
> What about having a configuration knob to indicate the behavior to
> follow when receiving SHL=0? A domain that involves classifiers/SFFs
> that understand SHL must not forward or accept receiving packets with SHL=0.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :*Dave Dolson [mailto:[e-mail]]
> *Envoyé :* mardi 2 mai 2017 14:41
> *À :* BOUCADAIR Mohamed IMT/OLN; James N Guichard; Greg Mirsky
> *Cc :* [e-mail]; Ron Parker
> *Objet :* RE: [sfc] TTL field within the NSH base header
>
>
>
> Med,
>
> I agree.
>
> Consider the case when a “new” SFF is added to an existing system:
>
> For all NSH packets, the Hop Limit/TTL field is zero, not just those
> from the classifier.
>
>
>
> I object to this statement of yours:
>
>> add a sentence saying that “an incoming value of 0” is only acceptable from a classifier.
>
>
>
> As I see it, an incoming value of 0 is acceptable from any source.
>
>
>
> -Dave
>
>
>
> *From:*[e-mail]
> <mailto:[e-mail]> [mailto:[e-mail]]
> *Sent:* Tuesday, May 2, 2017 7:58 AM
> *To:* Dave Dolson; James N Guichard; Greg Mirsky
> *Cc:* [e-mail] <mailto:[e-mail]>; Ron Parker
> *Subject:* RE: [sfc] TTL field within the NSH base header
>
>
>
> Hi Dave,
>
>
>
> SFFs that do not support SHL will preserve these bits as received. In
> other words, these SFFs won’t reset these bits to zeros.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :*Dave Dolson [mailto:[e-mail]]
> *Envoyé :* mardi 2 mai 2017 12:19
> *À :* BOUCADAIR Mohamed IMT/OLN; James N Guichard; Greg Mirsky
> *Cc :* [e-mail] <mailto:[e-mail]>; Ron Parker
> *Objet :* Re: [sfc] TTL field within the NSH base header
>
>
>
> Med,
>
> For the backwards compatibility case, we also support ‎SFFs that do not
> decrement TTL/Hop Limit. Saying a value of zero can only come from
> classifiers defeats that, as well as adding unnecessary complexity.
>
>
>
> David Dolson
> ‎
>
> *From: *[e-mail] <mailto:[e-mail]>
>
> *Sent: *Tuesday, May 2, 2017 2:17 AM
>
> *To: *James N Guichard; Greg Mirsky; Dave Dolson
>
> *Cc: *[e-mail] <mailto:[e-mail]>; Ron Parker
>
> *Subject: *RE: [sfc] TTL field within the NSH base header
>
>
>
> Hi Jim,
>
>
>
> Thank you for this updated proposal. This is much more better.
>
>
>
> Giving the clarification discussed with Joel (i.e., do not reset
> reserved bits by intermediate devices), I wonder whether it makes sense
> to add a sentence saying that “an incoming value of 0” is only
> acceptable from a classifier.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :*James N Guichard [mailto:[e-mail]]
> *Envoyé :* lundi 1 mai 2017 19:39
> *À :* Greg Mirsky; Dave Dolson
> *Cc :* [e-mail] <mailto:[e-mail]>; BOUCADAIR Mohamed IMT/OLN;
> Ron Parker
> *Objet :* RE: [sfc] TTL field within the NSH base header
>
>
>
> Okay lots of conversation but let me offer a revised version of Med’s
> text that hopefully captures most of the discussion (changes highlighted):
>
>
>
> SHL (SFF Hop Limit): Indicates the maximum SFF hops for an *SFP*. The
> initial SHL value SHOULD be configurable via the control plane; the
> configured initial value can be specific to *one or more SFPs*. If no
> initial value is explicitly provided, the default initial SHL value 63
> MUST be used. Each SFF involved in forwarding an NSH packet MUST
> decrement *the *SHL value by 1 *prior to NSH forwarding lookup*.
> *Decrementing by 1 from an incoming value of 0 shall result in a SHL
> value of 63. The packet MUST NOT be forwarded if SHL is, after
> decrement, 0 e.g. decrement SHALL occur before testing SHL for 0. *
>
>
>
> Jim
>
>
>
>
>
> *From:*Greg Mirsky [mailto:[e-mail]]
> *Sent:* Monday, May 01, 2017 1:02 PM
> *To:* Dave Dolson <[e-mail] <mailto:[e-mail]>>
> *Cc:* [e-mail] <mailto:[e-mail]>; [e-mail]
> <mailto:[e-mail]>; James N Guichard
> <[e-mail] <mailto:[e-mail]>>; Ron
> Parker <[e-mail]
> <mailto:[e-mail]>>
> *Subject:* Re: [sfc] TTL field within the NSH base header
>
>
>
> "Be liberal what you accept. Be conservative what you send."
>
> I think this sums what we have discussed - accept TTL 0, don't forward
> TTL 0.
>
>
>
> Regards, Greg
>
>
>
> On May 1, 2017 8:58 AM, "Dave Dolson" <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     Ron,
>
>     I too would like simple, but your table looks pretty complicated.
>     And I think it adds configuration for an SFF to know whether there
>     are others before it.
>
>     My version of simple:
>
>       TTL field of 0 means 64.
>
>       Every SFF decrements TTL each time it forwards the NSH packet. If
>     decrementing from 1 would result in under-flow to 64, discard.
>
>
>
>
>
>
>
>
>
>     *From:*Ron Parker [mailto:[e-mail]
>     <mailto:[e-mail]>]
>     *Sent:* Monday, May 1, 2017 11:41 AM
>
>
>     *To:* Dave Dolson; James N Guichard; [e-mail]
>     <mailto:[e-mail]>; [e-mail]
>     <mailto:[e-mail]>
>     *Subject:* RE: TTL field within the NSH base header
>
>
>
>     Agree that I’d opt for precision over simplicity.   Which is what I
>     tried to convey a ways back on this thread regarding differentiated
>     behavior at the last SFF in the SFP vs. the non-last SFF in the
>     SFP.    Subsequent comments didn’t seem to embrace that way of
>     describing things.    Also, if there were consensus to supporting
>     that approach, backward compatibility for classifiers that emit
>     TTL=0 could be addressed by also describing behavior at the first
>     SFF vs. non-first.
>
>
>
>
>
>     	
>
>     TTL=1
>
>     	
>
>     TTL=0
>
>     Only SFF (First and last)
>
>     	
>
>     Valid – service local SF’s
>
>     	
>
>     Valid for backward compatibility – service local SF’s
>
>     First SFF and not Last
>
>     	
>
>     Invalid – drop (since propagation to subsequent SFF with TTL=0 is
>     illegal)
>
>     	
>
>     Valid for backward compatibility – service local SF’s and propagate
>     to subsequent SFF with TTL=63
>
>     Last SFF when >1 SFF’s for SFP
>
>     	
>
>     Valid – service local SF’s
>
>     	
>
>     Invalid –drop (due to bad behavior of previous SFF)
>
>
>
>     *From:*Dave Dolson [mailto:[e-mail]]
>     *Sent:* Monday, May 1, 2017 11:25 AM
>     *To:* Ron Parker <[e-mail]
>     <mailto:[e-mail]>>; James N Guichard
>     <[e-mail] <mailto:[e-mail]>>;
>     [e-mail] <mailto:[e-mail]>;
>     [e-mail] <mailto:[e-mail]>
>     *Subject:* RE: TTL field within the NSH base header
>
>
>
>     I think precision in the definition is important for when expects
>     certain behavior for small values of TTL. E.g., by using trace-route
>     type of tools.
>
>     We can’t just wave our hands and say drop packets with TTL near 0 or
>     1 or 2.
>
>
>
>     If one has a chain of 3 items, a TTL of 6 should work. (SFFs receive
>     packets 6 times in the system diagram that is usually drawn).
>
>
>
>     (Simplified: I realize in some systems more SFF interactions are
>     required.)
>
>
>
>
>
>
>
>
>
>     *From:*Ron Parker [mailto:[e-mail]]
>     *Sent:* Monday, May 1, 2017 11:14 AM
>     *To:* Dave Dolson; James N Guichard; [e-mail]
>     <mailto:[e-mail]>; [e-mail]
>     <mailto:[e-mail]>
>     *Subject:* RE: TTL field within the NSH base header
>
>
>
>     Agree that differentiating “forwarding” to attached SF instances vs
>     subsequent SFF’s is logical and intuitive (to me) and I prefer to
>     acknowledge that there is a difference.   But, I was addressing a
>     suggestion to simplify.     In practice, 61 or 62 or 63 decrements
>     of TTL all probably mean the same thing J.
>
>
>
>        Ron
>
>
>
>
>
>     *From:*Dave Dolson [mailto:[e-mail]]
>     *Sent:* Monday, May 1, 2017 11:11 AM
>     *To:* Ron Parker <[e-mail]
>     <mailto:[e-mail]>>; James N Guichard
>     <[e-mail] <mailto:[e-mail]>>;
>     [e-mail] <mailto:[e-mail]>;
>     [e-mail] <mailto:[e-mail]>
>     *Subject:* RE: TTL field within the NSH base header
>
>
>
>     There is a difference between dropping the packet at receive vs.
>     transmit.
>
>     A **terminating** SFF may accept a packet with TTL=1.  I.e., where
>     the NSH header is removed.
>
>     What matters is that it is not decremented to zero and forwarded as NSH.
>
>
>
>     Otherwise we’d say, “huh, no point in sending a packet if TTL=1. And
>     huh, if received with TTL=2 then we might as well drop it…” Recurse
>     ad absurdum.
>
>
>
>     Hence, the correct language needs to convey that a device
>     decrementing TTL (in order to forward NSH) must check if it would
>     result in zero.
>
>
>
>     This conveys that, I think:
>
>     The packet MUST NOT be forwarded to a next hop if SHL is decremented
>     to zero.
>
>
>
>
>
>     -Dave
>
>
>
>
>
>     *From:*Ron Parker [mailto:[e-mail]]
>     *Sent:* Monday, May 1, 2017 10:50 AM
>     *To:* James N Guichard; [e-mail]
>     <mailto:[e-mail]>; Dave Dolson; [e-mail]
>     <mailto:[e-mail]>
>     *Subject:* RE: TTL field within the NSH base header
>
>
>
>     We could simplify this by saying that an SFF that receives an NSH
>     packet with TTL=1 shall drop the packet.   That doesn’t require any
>     distinction of the type of forwarding.    You could argue that
>     perhaps 1 means take care of local SF’s, only, but then we are back
>     to having to make that distinction.    Given that we are starting at
>     63 by default, finessing what happens when receiving 1 doesn’t seem
>     worthwhile to me.
>
>
>
>     *From:*James N Guichard [mailto:[e-mail]]
>     *Sent:* Monday, May 1, 2017 10:45 AM
>     *To:* Ron Parker <[e-mail]
>     <mailto:[e-mail]>>;
>     [e-mail] <mailto:[e-mail]>;
>     Dave Dolson <[e-mail] <mailto:[e-mail]>>;
>     [e-mail] <mailto:[e-mail]>
>     *Subject:* RE: TTL field within the NSH base header
>
>
>
>     Yes but my point was if the SFF is **terminating** the service chain
>     there are no service functions left to be forwarded to so the
>     sentence does not make any sense. If however the SFF is terminating
>     the service chain and at termination the SHL reaches 0 then it
>     should still forward the packet (after removal of NSH).
>
>
>
>     Jim
>
>
>
>     *From:*Ron Parker [mailto:[e-mail]]
>     *Sent:* Monday, May 01, 2017 10:28 AM
>     *To:* James N Guichard <[e-mail]
>     <mailto:[e-mail]>>; [e-mail]
>     <mailto:[e-mail]>; Dave Dolson
>     <[e-mail] <mailto:[e-mail]>>; [e-mail]
>     <mailto:[e-mail]>
>     *Subject:* RE: TTL field within the NSH base header
>
>
>
>     I’d like to disambiguate the word “forwarding”.   From SFF
>     perspective, there is forwarding to attached SF instances and there
>     is forwarding to other SFFs.
>
>
>
>     “SFFs that terminate a service chain MUST forward the packet to
>     attached service functions, even if SHL is decremented to 0”
>
>
>
>        Ron
>
>
>
>
>
>
>
>     *From:*sfc [mailto:[e-mail]] *On Behalf Of *James N Guichard
>     *Sent:* Monday, May 1, 2017 10:22 AM
>     *To:* [e-mail]
>     <mailto:[e-mail]>; Dave Dolson
>     <[e-mail] <mailto:[e-mail]>>; [e-mail]
>     <mailto:[e-mail]>
>     *Subject:* Re: [sfc] TTL field within the NSH base header
>
>
>
>     I don’t understand this sentence as if an SFF is terminating a
>     service chain then it **wont** be forwarding the packets to attached
>     SFs; Shouldn’t this sentence read “SFFs that terminate a service
>     chain MUST forward the packet even if SHL is decremented to 0” ?
>
>
>
>     Jim
>
>
>
>     *From:*[e-mail]
>     <mailto:[e-mail]>
>     [mailto:[e-mail]]
>     *Sent:* Friday, April 28, 2017 10:38 AM
>     *To:* Dave Dolson <[e-mail]
>     <mailto:[e-mail]>>; James N Guichard
>     <[e-mail] <mailto:[e-mail]>>;
>     [e-mail] <mailto:[e-mail]>
>     *Subject:* RE: TTL field within the NSH base header
>
>
>
>     Re-,
>
>
>
>     I see SHL as a means to prevent SFF loops. There is no value in
>     deleting a packet after an SFF decrement the SHL to 0, but that
>     packet is to be passed to SFs that are attached to this SFF. The
>     packet will be forwarded after stripping the NSH header; no risk for
>     SFF loops out there. No?
>
>
>
>     Cheers,
>
>     Med
>
>
>
>     *De :*Dave Dolson [mailto:[e-mail]]
>     *Envoyé :* vendredi 28 avril 2017 16:29
>     *À :* BOUCADAIR Mohamed IMT/OLN; James N Guichard; [e-mail]
>     <mailto:[e-mail]>
>     *Objet :* RE: TTL field within the NSH base header
>
>
>
>     Med,
>
>
>
>     “SFFs that terminate a service chain MUST forward the packet to
>     attached SFs even if SHL is decremented to 0.”
>
>     I don’t think this is right.
>
>     If TTL/SHL is decremented to 0, this must not be forwarded as NSH.
>
>     I see that **receiving** a packet with SHL=1 can result in chain
>     termination, i.e., NSH decapsulation. But not forwarding as NSH with
>     SHL=0.
>
>
>
>     -Dave
>
>
>
>
>
>     *From:*sfc [mailto:[e-mail]] *On Behalf Of
>     *[e-mail] <mailto:[e-mail]>
>     *Sent:* Friday, April 28, 2017 9:36 AM
>     *To:* James N Guichard; [e-mail] <mailto:[e-mail]>
>     *Subject:* Re: [sfc] TTL field within the NSH base header
>
>
>
>     Hi Jim, all,
>
>
>
>     I have the following comments :
>
>     ·        Change “TTL” to “SFF Hop Limit (SHL)” because this field is
>     not about a time to live but about a limit of SFF hops to be crossed.
>
>     ·        I don’t understand what is meant by “testing”.
>
>     ·        I suggest to make this change to cover the following points:
>
>     o   SHL should be configurable by the control plane.
>
>     o   Packets can be forwarded to SFs even if SHL is decremented to 0
>     for the terminating SFF.
>
>     o   I don’t think it is a good idea to include “Decrementing by a
>     value of 1 from 0 shall result in a TTL value of 63” because this
>     will lead to a broken mechanism.
>
>
>
>     OLD:
>
>     TTL: Service plane time-to-live. An SFF MUST decrement the TTL by a
>     value of 1 for all NSH packets it receives. Decrementing by a value
>     of 1 from 0 shall result in a TTL value of 63. The default for
>     originating an NSH packet is a TTL value of 63. The decrement SHALL
>     occur before testing for 0. After decrement, if the TTL is 0, the
>     NSH packet MUST NOT be forwarded.
>
>
>
>     NEW:
>
>     SHL (SFF Hop Limit): Indicates the maximum SFF hops for a service
>     chain. The initial SHL value SHOULD be configurable via the control
>     plane; the configured initial value can be specific to a chain or
>     all chains. If no initial value is explicitly provided, the default
>     initial SHL value 63 MUST be used. Each SFF involved in forwarding
>     an NSH packet MUST decrement SHL value by 1. The packet MUST NOT be
>     forwarded to a next hop SFF if SHL is decremented to zero. SFFs that
>     terminate a service chain MUST forward the packet to attached SFs
>     even if SHL is decremented to 0.
>
>
>
>     Thank you.
>
>
>
>     Cheers,
>
>     Med
>
>
>
>     *De :*sfc [mailto:[e-mail]] *De la part de* James N Guichard
>     *Envoyé :* jeudi 27 avril 2017 20:54
>     *À :* [e-mail] <mailto:[e-mail]>
>     *Objet :* [sfc] TTL field within the NSH base header
>
>
>
>     Dear WG:
>
>
>
>     Having reviewed all of the email discussion on the mailing list it
>     appears to the chairs that we have consensus to add a TTL field to
>     the NSH base header. We would like to propose the following changes:
>
>
>
>     Section 3.2:
>
>     Update figure 2 as follows:
>
>
>
>          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>         |Ver|O|R|    TTL    |   Length  |R|R|R|R|MD Type| Next Protocol |
>
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
>     Add the following text after figure 2:
>
>
>
>     TTL: Service plane time-to-live. An SFF MUST decrement the TTL by a
>     value of 1 for all NSH packets it receives. Decrementing by a value
>     of 1 from 0 shall result in a TTL value of 63. The default for
>     originating an NSH packet is a TTL value of 63. The decrement SHALL
>     occur before testing for 0. After decrement, if the TTL is 0, the
>     NSH packet MUST NOT be forwarded.
>
>
>
>     Section 3.4:
>
>     Update figure 4 to reflect the new base header format as per section
>     3.2 base header.
>
>
>
>     Section 3.5:
>
>     Update figure 5 to reflect the new base header format as per section
>     3.2 base header.
>
>
>
>     Section 12.2.1:
>
>     Current text is as follows:
>
>
>
>        There are ten bits at the beginning of the NSH Base Header.  New bits
>
>        are assigned via Standards Action [RFC5226].
>
>
>
>        Bits 0-1 - Version
>
>        Bit 2 - OAM (O bit)
>
>        Bit 3 - Critical TLV (C bit)
>
>        Bits 4-9 - Reserved
>
>
>
>     Replace entire text as follows:
>
>
>
>        There are eight reserved bits in the NSH Base Header. New bits
>
>        are assigned via Standards Action [RFC5226].
>
>
>
>        Bits 0-1 - Version
>
>        Bit 2 - OAM (O bit)
>
>        Bit 3 - Reserved
>
>        Bits 16-19 - Reserved
>
>
>
>     Section 12.2.3:
>
>     Current text has the MD-type as 8-bit values.
>
>
>
>     Update text for this section and table 1 to reflect 4-bit values
>     *not* 8-bit values.
>
>
>
>     *Please review carefully and indicate support for these changes (or
>     any changes to the suggested text).*
>
>     * *
>
>     Thanks,
>
>
>
>     Jim & Joel
>
>
>
>
>
>
>
>
>
>
>
>
>     _______________________________________________
>     sfc mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/sfc
>
>
>
>
>
> _______________________________________________
> sfc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sfc
>