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

The distinction has been made frequently.
For example, section 7.1 of the NSH document has separate tables 
describing the information needed by an SFF to forward to the next SFF. 
That table includes indication of the transport and next hop address to 
be used.
In contrast, the summary of information about forwarding toi service 
functions only includes an identification of the SF, as the forwarding 
mechanism for that communication is outside of our scope.

Yours,
Joel

On 5/1/17 10:42 AM, Kyle Larose wrote:
> Do we really need to complicate SFFs by having them understand whether
> they are forwarding to an SF or an SFF? Has that distinction been made
> previously? If not, I question whether it’s worth forcing it to be made
> now just to add one more hop to the path.
>
>
>
> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Ron Parker
> *Sent:* Monday, May 01, 2017 10:28 AM
> *To:* James N Guichard; mohamed.boucadair@orange.com; Dave Dolson;
> sfc@ietf.org
> *Subject:* Re: [sfc] 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; Dave Dolson <ddolson@sandvine.com>;
> 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
>