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

[Joe Clarke <[e-mail]>]

On 5/1/17 13:38, James N Guichard wrote:
> 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. *

I think this text is clearer, and I agree (on the other thread) TTL
makes more sense vs. a new piece of terminology.

I still wonder if it's worth explicitly stating that this underrun
methodology is there to support backwards compat?

Joe

> 
>  
> 
> Jim
> 
>  
> 
>  
> 
> *From:*Greg Mirsky [mailto:[e-mail]]
> *Sent:* Monday, May 01, 2017 1:02 PM
> *To:* Dave Dolson <[e-mail]>
> *Cc:* [e-mail]; [e-mail]; James N Guichard
> <[e-mail]>; Ron Parker <[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
>