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

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

Personally, I would not say "MUST NOT".  It is a statement of effect 
that if all devices in the environment support the RFC, with TTL (SHL) 
defined as proposed, then

no NSH processing device will ever receive a packet with the TTL (SHL) 
field set to 0.

That is a statement of fact.  As I see it, it is not an interoperability 
requirement.  If such a packet is received, the right thing will happen.

Yours,
Joel

On 5/2/17 9:38 AM, [e-mail] wrote:
> Re-,
>
>
>
> I don’t get your point, Dave.
>
>
>
> My concern is how to detect a misbehaving node vs a node that is not
> supporting SHL.
>
>
>
> If all nodes in a domain support SHL, then packets with SHL==0 MUST NOT
> be received by any SFF of that domain. Do you agree with that?
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :*Dave Dolson [mailto:[e-mail]]
> *Envoyé :* mardi 2 mai 2017 15:20
> *À :* BOUCADAIR Mohamed IMT/OLN; James N Guichard; Greg Mirsky
> *Cc :* [e-mail]; Ron Parker
> *Objet :* RE: [sfc] TTL field within the NSH base header
>
>
>
> I still think the conceptual difficulty goes away if we say that the 6
> bits 000000 represents the value 64.
>
>
>
>
>
>
>
> *From:*[e-mail]
> <mailto:[e-mail]> [mailto:[e-mail]]
> *Sent:* Tuesday, May 2, 2017 8:53 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
>
>
>
> 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] <mailto:[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
>