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

The summary I sent to the list, based on what little I could tell of 
rough consensus, was to only decrement TTL at SFF.  If you want to argue 
for decrementing at all NSH-aware devices, state your case.

Yours,
Joel

On 5/1/17 12:50 PM, Ron Parker wrote:
> Is there a decrement for each SF, too.?   In the past we've talked about
> decrement only between SFFs.
>
> On May 1, 2017, at 11:56 AM, Dave Dolson <ddolson@sandvine.com
> <mailto:ddolson@sandvine.com>> 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:Ron_Parker@affirmednetworks.com]
>> *Sent:* Monday, May 1, 2017 11:41 AM
>> *To:* Dave Dolson; James N Guichard; mohamed.boucadair@orange.com
>> <mailto:mohamed.boucadair@orange.com>; sfc@ietf.org <mailto:sfc@ietf.org>
>> *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:ddolson@sandvine.com]
>> *Sent:* Monday, May 1, 2017 11:25 AM
>> *To:* Ron Parker <Ron_Parker@affirmednetworks.com
>> <mailto:Ron_Parker@affirmednetworks.com>>; James N Guichard
>> <james.n.guichard@huawei.com <mailto:james.n.guichard@huawei.com>>;
>> mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>;
>> sfc@ietf.org <mailto:sfc@ietf.org>
>> *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:Ron_Parker@affirmednetworks.com]
>> *Sent:* Monday, May 1, 2017 11:14 AM
>> *To:* Dave Dolson; James N Guichard; mohamed.boucadair@orange.com
>> <mailto:mohamed.boucadair@orange.com>; sfc@ietf.org <mailto:sfc@ietf.org>
>> *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:ddolson@sandvine.com]
>> *Sent:* Monday, May 1, 2017 11:11 AM
>> *To:* Ron Parker <Ron_Parker@affirmednetworks.com
>> <mailto:Ron_Parker@affirmednetworks.com>>; James N Guichard
>> <james.n.guichard@huawei.com <mailto:james.n.guichard@huawei.com>>;
>> mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>;
>> sfc@ietf.org <mailto:sfc@ietf.org>
>> *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:Ron_Parker@affirmednetworks.com]
>> *Sent:* Monday, May 1, 2017 10:50 AM
>> *To:* James N Guichard; mohamed.boucadair@orange.com
>> <mailto:mohamed.boucadair@orange.com>; Dave Dolson; sfc@ietf.org
>> <mailto:sfc@ietf.org>
>> *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:james.n.guichard@huawei.com]
>> *Sent:* Monday, May 1, 2017 10:45 AM
>> *To:* Ron Parker <Ron_Parker@affirmednetworks.com
>> <mailto:Ron_Parker@affirmednetworks.com>>;
>> mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>;
>> Dave Dolson <ddolson@sandvine.com <mailto:ddolson@sandvine.com>>;
>> sfc@ietf.org <mailto:sfc@ietf.org>
>> *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:Ron_Parker@affirmednetworks.com]
>> *Sent:* Monday, May 01, 2017 10:28 AM
>> *To:* James N Guichard <james.n.guichard@huawei.com
>> <mailto:james.n.guichard@huawei.com>>; mohamed.boucadair@orange.com
>> <mailto:mohamed.boucadair@orange.com>; Dave Dolson
>> <ddolson@sandvine.com <mailto:ddolson@sandvine.com>>; sfc@ietf.org
>> <mailto:sfc@ietf.org>
>> *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:sfc-bounces@ietf.org] *On Behalf Of *James N Guichard
>> *Sent:* Monday, May 1, 2017 10:22 AM
>> *To:* mohamed.boucadair@orange.com
>> <mailto:mohamed.boucadair@orange.com>; Dave Dolson
>> <ddolson@sandvine.com <mailto:ddolson@sandvine.com>>; sfc@ietf.org
>> <mailto:sfc@ietf.org>
>> *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:* mohamed.boucadair@orange.com
>> <mailto:mohamed.boucadair@orange.com>
>> [mailto:mohamed.boucadair@orange.com]
>> *Sent:* Friday, April 28, 2017 10:38 AM
>> *To:* Dave Dolson <ddolson@sandvine.com
>> <mailto:ddolson@sandvine.com>>; James N Guichard
>> <james.n.guichard@huawei.com <mailto:james.n.guichard@huawei.com>>;
>> sfc@ietf.org <mailto:sfc@ietf.org>
>> *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:ddolson@sandvine.com]
>> *Envoyé :* vendredi 28 avril 2017 16:29
>> *À :* BOUCADAIR Mohamed IMT/OLN; James N Guichard; sfc@ietf.org
>> <mailto:sfc@ietf.org>
>> *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:sfc-bounces@ietf.org] *On Behalf Of
>> *mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>
>> *Sent:* Friday, April 28, 2017 9:36 AM
>> *To:* James N Guichard; sfc@ietf.org <mailto:sfc@ietf.org>
>> *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:sfc-bounces@ietf.org] *De la part de* James N Guichard
>> *Envoyé :* jeudi 27 avril 2017 20:54
>> *À :* sfc@ietf.org <mailto:sfc@ietf.org>
>> *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
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc
>